Autoři reloaded

3.12.2006 18:26 | Přečteno: 1367× | Abíčko | | poslední úprava: 3.12.2006 18:31

aneb další větší změna. Yin naimplementoval bug 469, což je podpora více autorů pro jeden článek. Nicméně jsme to vzali zgruntu a vyřešili i další problémy. Například zlepšit výkon při prohlížení článků určitého uživatele, samostatná stránka s hezkým url pro každého autora, autor už nemusí být uživatelem Abíčka, autor si už nemůže svévolně změnit jméno na nějaký nesmysl, u autora ukládáme jeho osobní údaje pro potřebu redakce. První verze vypadá funkčně, snad brzy tuto funkcni vylepšíme a přidáme další funkce, třeba text o autorovi či foto.

Teď me začíná trápit velikost dat v tabulce revize, což je primitivní implementace SCM. Verzování bylo snadné na implementaci a je maximálně rychlé, protože neukládám diffy ale celá data. Objem dat začíná být problém a měl bych jej začít řešit zavčasu. Mohli bychom poskytnout finanční odměnu, kdyby mě toho problému někdo zbavil. Požadavky: pure java, změny se týkají jen starších revizí (tabulka revize), mezi revizemi se ukládají jen diffy, diffy ignorují řádky (když někdo napíše dlouhý odstavec a někdo jiný změní jeden překlep, aby changeset obsahoval jen index a změnu, klasický diff vypíše index, původní řádek a změněný řádek). Pokud se do toho někdo chce pustit, nechť mě kontaktuje a domluvíme se na podrobnostech.

       

Komentáře

[freshmouse]

Pozor na logiku URL.

něco.cz/muj_obsah/uzivatel-1569599 je daleko méně logické než něco.cz/uzivatel-1569599/muj_obsah.

Představ si to jako souborový systém:

- uživatel
   - uživatel 1
      - uživatelůb obsah
         - články
         - komentáře
         - zprávičky
      - uživatelův weblog
   - uživatel 2
      - uživatelůb obsah
         - články
         - komentáře
         - zprávičky
      - uživatelův weblog
- články
   - článek číslo 1
      - komentáře
         - syndikace komentářů (RSS)
   - článek číslo 2
      - komentáře
         - syndikace komentářů (RSS)
- software
   - skupina software 1
      - podskupina software 1
         - software číslo 1
   - skupina software 2
      - podskupina software 3
         - software číslo 2

A tak dále.

[Leoš Literák]

To url muj_obsah byla jen narychlo provedena oprava pred webroboty, abych jim mohl zakazat prohlizet tuto vypocetne narocnou stranku. Az jednou budu predelavat uzivatele (a potrebuji to), budu si davat bacha. Zatim ani nevim, jaka zvolim URL, zda /profil/literakl nebo /profil/leos-literak, nebo pouzivat /uzivatel misto /profil .. ?

[freshmouse]

Rozhodně používat "uzivatel" -- říká to víc než "profil" (ale méně než Raffaelo). Co se týče jmen uživatelů v URL, klidně bych tam dal jen jejich ID, protože to má "trvalejší" charakter. Naopak u komentářů u článků a u diskuzí bych dal název článku / diskuze: - /clanky/nazev-clanku/komentare/
- /diskuze/nazev-diskuze/ ... namísto /forum/show/12345. Je to daleko logičtější. (U toho článku bych dokonce dělal URL ve stylu: /clanky/2006/12/nazev-clanku -- pak to bude ještě lepší.) Dále, do URL patří pomlčky, ne podtržítka. Má to určitý vliv na vyhledavače, i když ne moc velký. Daleko důležitější jsou HTML tagy <title>. Ty bych tvořil podobně jako ta URL, např.: - Název článku (ABCLinuxu: Linux na stříbrném podnose)
- ABCLinuxu: Linux na stříbrném podnose > Název článku Atd. Myslím, že toto téma docela ovládám, takže rád pomůžu (Jabber: freshmouse (A v kroužku) jabber.org).

[Leoš Literák]

Zkontroluj si aktualni stav, polovina z toho je davno hotova

[freshmouse]

Záleží na úhlu pohledu. Já vidím tu nehotovou polovinu.

[Yin]

Ja nevidim ani tu polovicu... a som stastny ;)

[freshmouse]

Je ovšem otázka, jestli se koukáš!

[Leoš Literák]

http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-1.-11.-2006/diskuse - diskuse ma vlastni textove URL, pouzivame pomlcky, rozdil od podtrzitek je pro google obrovsky.

Davat datum do url clanku se mi nechce, i kdyz svuj puvab by to melo. Jenze pak bych musel delat handlery pro url typu /clanky/jaderne-noviny/2006/12, jako v blogu a to se mi nechce. Dost prace, pomerne slozita logika, viz blogy.

URL pro dotazy ve foru jsou v planu, ale mam jeden problem a to, ze spousta dotazu je ve spatnem foru nebo ma nesmyslny titulek, pripadne se opakuje. Pro vsechno sice mame reseni (ulozit stare URL do tabulky redirektu), detekce duplikatnich URL, ale zatim jsem se k tomu nedostal.

Z uzivatelskeho hlediska je lepsi mit titulek, ktery obsahuje variabilni cast na zacatku, protoze jinak v taskbaru uvidis petkrat AbcLinuxu ..., ale nerozeznas, co je v kterem tabu. Na to se snazime davat pozor.

[Honza Jaroš]

Co se týče toho diffu, docela by mě zajímalo, co použít. Já v jednom malém projektu používám knihovnu javaxdelta, ale tam se nějak dlouhodobě nic neděje, zdrojáky jsou dostupné pouze přes CVS a ačkoli jsou funkční a s problémy jsem se nesetkal, nejsem si jist, jestli je to nejvhodnější volba. Má někdo rozumnou javovskou alternativu pro binární diff?

[Leoš Literák]

Diky za URL, prozkoumam jej. Zatim jsem si popsal algoritmus do bugzilly. IMHO by mel fungovat.

[Honza Jaroš]

Nebylo by výpočetně méně náročné ukládat naopak diffy vždy proti poslední revizi? Že by aktuální revize, se kterou se obvykle nejvíc pracuje, byla čistý text a při změně by se naopak uložil diff vůči současnému stavu? Takže pokud by někdo chtěl nějakou starší verzi, načetla by se nejdřív ta současná a od ní by se postupovalo přes diffy zpět do minulosti.

[Leoš Literák]

V tom popisu jsem nezminil, ze aktualni verze je drzena v normalnich tabulkach, zmena se tyka jen tabulky revize, kde se uklada historie dokumentu.

Tvuj pristup ma jednu vadu a to, ze po kazde zmene by se musely prepocitat i starsi revize, ne? Aspon na prvni pohled mi to tak pripada. Ted na to nemam cas, ale zkusim to pozdeji promyslet, zda to tak skutecne je. Aspon si zatim napisu testovaci data.

• Tohle je prvni revize.
• Tohle je zmenena druha revize.
• Tohle neni druha revize.

Muj puvodni navrh je ulozit takovato data:

• 1, "Tohle je prvni revize.", NULL
• 2, NULL, "[9,5,\"zmenena druha\"]"
• 3, NULL, "[6,16,\"neni druha\"]"

[Honza Jaroš]

Není potřeba to přepočítávat. V obou přístupech se uchovávají diffy pouze mezi verzemi následujícími po sobě, pouze u tebe se aplikováním diffu na předchozí verzi dostane verze aktuální, kdežto u mně je tomu naopak. Ale postup řadou verzí je jinak stejný, jen se děje z opačného konce. V té mojí miniwiki to takhle používám - ovšem já tam při zobrazení stránky (pominu-li cache) tahám data skutečně z tabulky revizí. Pokud má Abíčko ještě někde uchován nezávislý čistý text aktuální revize pro účely zobrazení, je to asi fuk, jestli to diffovat od začátku nebo od konce.

[Honza Jaroš]

Raději ještě doplním názorné srovnání: Tvůj přístup:
První verze -(diff)> druhá verze -(diff)> třetí verze Můj přístup:
Třetí verze -(diff)> Druhá verze -(diff)> první verze Pokud přidávám další verzi, udělám pouze diff mezi třetí a čtvrtou verzí a postup při získávání úplně původní revize pak bude Čtvrtá verze -(diff)> třetí -(diff)> druhá -(diff)> první v mém případě, nebo První verze -(diff)> druhá -(diff)> třetí -(diff)> čtvrtá ve tvém případě při získávání poslední revize. Jak jsem psal, vycházel jsem z toho, že poslední revize by se tahala častěji než první, takže by při jejím získávání nebylo potřeba procházet verzemi od začátku. Pokud je ovšem tabulka revizí používána pouze při přístupu k některé předchozí verzi a při změně textu, je to asi vcelku jedno.

[Honza Jaroš]

Samozřejmě při ukládání nové verze je potřeba přepsat i tu poslední předchozí a nahradit v ní čistý text pouze diffem.

[Leoš Literák]

Cestou na obed jsem o tom uvazoval a mas pravdu, tohle fungovat bude. Dokonce optimalneji, nez muj pristup, protoze za prve pri ukladani dalsi revize se rychleji dostanes k textu posledni ulozene revize (staci ti jediny diff) a za druhe je pravdepodobnejsi, ze uzivatele budou prohlizet posledni revize nez ty nejstarsi.

Ted jsou tu ale implementacni rozhodnuti. Kdyz se podivas do zdrojaku, pak revize mam napsany naprosto obecne, nejsou svazany s datovym modelem. Takze teoreticky mohu verzovat cokoliv. Pokud bych ale potreboval ziskat aktualne ulozeny text, znamenalo by to svazat revize s modelem nebo zeslozitet API (pridat puvodni text a novy text), coz se mi nelibi. Lepsi reseni jsi popsal ty - u posledni revize bude ulozen cely text, pri vkladani nove verze jej nahradit diffem a vlozit do nove revize aktualni text. Takze v tabulce bude u posledni revize vzdy kompletni text.

[Leoš Literák]

Aktualni revize ve skutecnosti v databazi je odjakziva, tim je to jednodussi. Vice v bugzille

[Leoš Literák]

Dalsi drobne opravy, napriklad diskuse ke kvizu ve vypisu poslednich komentaru se konecne zobrazuje spravne. Dale par chyb u autoru.

[Leoš Literák]

Vyreseny dalsi dve bugy z bugzilly - 618 a 636 (TimerTask bezel prilis dlouho a dokonce se nekdy zaseknul), navic pridan antispam i do pokladani otazek ve foru, spamboti se naucili pouzivat preview

[Leoš Literák]

Ha, ted jsem resil docela zaludny problem pri generovani databaze pro developery abicka. Furt mi to padalo na duplicate key u slozeneho klice. Ale kdyz jsem to debugoval, jelo to v poradku. Jenze na plnou rychlost to vzdycky spadlo. Ale aby to bylo slozitejsi, tak to padalo na dvou mistech, neheuristicky. Nakonec jsem zkusil nahradit prikaz zjistujici posledni cislo revize prikazem zjistujicim maximalnim cislem revize a uz to jede.

select verze from verze where cesta=? order by kdy desc limit 0,1
select max(verze) from verze where cesta=?

IMHO by oba prikazy mely byt ekvivalentni, ale mysql si to zrejme nemysli.

[Honza Jaroš]

Nemělo v tom původním dotazu být order by verze desc? Pokud by měl sloupec "kdy" třeba duplicitní hodnoty...

(kód Ábíčka neznám, nestíhám ani vlastní projekty, takže jen odhaduju podle popisu)

[Leoš Literák]

Mas pravdu, to bude asi ten rozdil. Nejspise je presnost sloupce na sekundy a proto rozliseni podle datumu neni dostatecne. Tridit to podle verze by bylo jistejsi. Akorat ted mi zacina vrtat cervicek pochybnosti a kouknuti na schema jej potvrzuje - verze je definovana jako VARCHAR Zrejme jsou puvodne zamyslel moznost obecnych verzi (napriklad 1.4 ci 2.3.4). Nicmene odhaduju, ze alter sloupce revize na smallint by mohl fungovat, jsou tam jen cela cisla.