Jak na verzování?

3.4.2006 20:57 | Přečteno: 2706× | Java

Mám dotaz pro kolegy programátory, jak by řešili verzování objektů ukládáných do databáze.

Chci najít optimální způsob, jak verzovat objekty. U abíčka jsem si napsal jednu variantu, ale ta se mi moc nelíbí a pro jiné případy je nepoužitelná. Třeba mi poradíte.

Pod verzováním mám na mysli obdobu CVS. Tedy každá aktualizace nezmění identifikátor objektu, jen někam uloží novou revizi. Existuje seznam revizí a je možné snadno získat libovolnou revizi, ideálně je i porovnat. U souborů je to poměrně jednoduché, ale já to potřebuji pro objekty, či spíše graf objektů.

Představte si objekt A, který má atributy x (int), y (String) a z (třída Z) plus primární klíč id (int). Objekt z má atributy a (int) a b (String) plus primární klíč id (int). Teď se třeba změnila hodnota A.x nebo A.z.b. Uložím tedy změny a nějak se vytvoří nová revize. Tohle je výchozí stav, o kterém se budeme bavit. Tyhle objekty mají odpovídající tabulky, persistence by nejspíše byla přes Hibernate.

První variantou je, že se do tabulek přidá další sloupeček revize. Na první pohled to vypadá velice elegantně, přístup k jednotlivým revizím včetně jejich seznamu je snadný. Jenže to, že v té tabulce nejsou jen aktuální platná data dost zásadně ovlivní podobu SQL dotazů. Například najdi mi všechny objekty A setřízené podle atributu x pochopitelně musí brát v úvahu jen platná data. Naštěstí je možné přidat další sloupeček typu boolean označující, zda jde o poslední revizi a ten přidat do všech podmínek.

Druhá varianta je ponechat tabulku tak, jak je a místo toho udělat obdobnou tabulku pro ukládání revizí. Tím oddělíme fyzicky poslední revize od historických dat, což zjednoduší SQL dotazy, na druhou stranu budeme mít dvojnásobek tabulek.

Třetí varianta je nějak to ohákovat a zkusit namapovat do CVS (apod). To by asi byla prasárna a vedlo by to určitě ke spoustě problémů.

Jaké máte zkušenosti? Jak byste to řešili vy? Půjde hibernate uzpůsobit, aby při změnách ukládal revize místo běžných updatů? Další otázky si ponechám na příště, nechci tříštit diskusi.

       

Komentáře

[Sinuhet]

Jaky ocekavate pocet revizi na objekt? Jak caste budou operace nad revizemi oproti ziskavi pouze nejnovejsi verze? Jak slozite veci hodlate s temi revizemi provadet?

[Leoš Literák]

V podstate jde o wiki, takze rekneme ve vetsine pripadu maximalne desitky revizi na objekt. Starsi revize jen tehdy, kdyz o ne nekdo projevi zajem, takze o nekolik radu mene. To spise by se hodilo info o autorech revizi, cisle posledni revize apod. Coz se pripadne da dat primo do modelu jako dalsi atributy, pokud se nebudou primo tahat z databaze.

[Sinuhet]

Pak bych to vrazil do dvou tabulek. Sice da trochu praci sesmolit jejich synchronizaci, ale vyhnete se pripadnym pozdejsim problemum s vykonem.

[alblaho]

Ty dva nárvhy jsou celkem ekvivalentní, vždy něco za něco.

Aniž bych bych měl dost informací, víc se mi líbí "stínové" tabulky. Myslím si že větší počet tabulek sám o sobě ničemu nevadí (z hlediska výkonu) z hledisla složitosti modelu to taky nevadí, protože to nejsou nové entity, ale jen stíny.

Naproti tomu přidávat nové atributy a komplikovat dotazy mi moc příjemné nepříjde.

Ale jak k tomu znásilnit Hibernate nevím, protože jsem s tím nikdy aktivně nedělal. Konečné rozhodnutí by se možná mělo odvíjet právě od toho znásilnění.

[Leoš Literák]

No prave. At si vyberu kterekoliv reseni, vzdycky si dokazu najit nejake jeho nevyhody a naopak vyhody toho druheho reseni. Takze me zajima cizi nazor.

[Filip Jirsák]

Podle mne mají stínové tabulky jedinou výhodu, a tou je index pouze přes aktuální záznamy, což je vlastně záležitsot optimalizace indexu databáze, a to bych si nechával až pro opravdu kritické zatížení. Jinak mi přijdou spíš složitější, protože musím v jedné transakci načíst aktuální záznam, uložit ho do stínové tabulky, vymazat ho z aktuální tabulky a zapsat tam nový. Mimo jiné je tyhle operace nutné serializovat - záznamy jednoho objektu musím aktualizovat postupně. A to nebude žádná legrace tohle napsat (asi bude potřeba nějaký write zámek na řádek a SELECT FOR UPDATE). Pokud používám jenom jednu tabulku, o žádný záznam nepřijdu - prostě se budou postupně vkládat tak, jak přijdou.

Já bych tedy rozhodně volil jednu tabulku pro všechny revize a aktuální revizi zjišťovat dotazem (nebo mít udělaný pohled "aktuální revize").

[Leoš Literák]

Jde to delat i jednoduseji: update radku tabulky plus insert nove revize do stinovane tabulky.

[Filip Jirsák]

Pokud bych chtěl databázi jó ulehčit práci, tak bych udělal zvláštní tabulku, kde budou jen odkazy na aktuální verzi (id objektu + číslo aktuální revize), vlastní záznamy by pak byly v jedné tabulce. Ta pomocná tabulka by fungovala vpodstatě jako cache pro max(revize). Výhoda proti příznaku boolean je, že můžu kontrolovat referenční integritu (aktuální je vždy jen jeden objekt).

S příznakem aktuální_revize jako boolean by zase byl problém se zamykáním: Spustí se 2 transakce "souběžně" (tj. ne po sobě, ale jedna se spustí během trvání druhé), obě nastaví aktuální revizi na false, obě zapíšou novou verzi do DB a rázem mám dvě aktuální revize jednoho záznamu. Aby se tomuhle předešlo, musel bych zamykat pro zápis dokonce celou databázi. U speciální tabulky pro odkazy na aktuální verzi tenhle problém není, tam "poslední transakce vyhrává".

[Sinuhet]

O jakych transakcich hovorite? U tech co znam ja, se o takovehle veci stara databaze.

[Filip Jirsák]

Hovořím o takových transakcích, které mají běžné relační databáze - tedy buď se provede celá transakce, nebo nic. Ale různé transakce klidně můžou běžet vedle sebe, do té doby, než mění nějaký společný záznam. A já jsem popsal případ, kdy transakce nemění žádný společný záznam, tj. poběží vedle sebe, provedou se obě, a na konci mám dva objekty označené jako aktuální.

[Sinuhet]

do té doby, než mění nějaký společný záznam

o prispevek vyse

obě nastaví aktuální revizi na false

[Filip Jirsák]

Zamykat insert tím, že shodou okolností před každým tím insertem ve stejné transakci bude update na "stejné" záznamy je docela divoké - on se ten předpoklad může někdy vymstít. Třeba u prázdné tabulky, kde "stejné záznamy" je prázdní množina a tedy se nezamyká nic:

Začíná 1. transakce (1)
(1) TRANSACTION BEGIN
(1) UPDATE SET aktualni = false WHERE aktualni = true;
(1) -- tabulka je prázdná, tj. WHERE není splněno pro žádný řádek, žádný řádek se nazamyká
(1) INSERT INTO (aktualni) VALUES (true);
Začíná 2. transakce (2), 1. stále trvá
(2) BEGIN TRANSACTION
(2) UPDATE SET aktualni = false WHERE aktualni = true;
(2) -- 1. transakce stále není potvrzená, a nemá zamčený žádný řádek, takže UPDATE normálně proběhne nad prázdnou tabulkou, tj. žádný řádek se nezamyká
(1) TRANSACTION COMMIT
(1) -- do tabulky se zapisuje 1. řádek s aktualni=true
(2) INSERT INTO (aktualni) VALUES (true);
(2) TRANSACTION COMMIT
(2) -- do tabulky se zapisuje 2. řádek s aktualni=true
-- tabulka obsahuje dva řádky s aktualni=true

Stačí?

[Leoš Literák]

Nastesti v mem pripade nejde o financni transakce ani jadernou elektrarnu a tak muzu povazovat sanci, ze dva lide budou editovat stejny dokument ve stejnem okamziku a oba zmacknou enter na setinu sekundy stejne, za prilis malou

[Sinuhet]

Tim jste akorat dokazal, ze lze navrhnout tabulku a dotazy takovym zpusobem, ze vam pak nepomuze ani svecena voda.

[Filip Jirsák]

Vzhledem k tomu, že můj původní příspěvek byl o tom, že navrženou tabulku nepokládám zrovna za nejlepší řešení, bylo to přesně to, co jsem chtěl dokázat

[Sinuhet]

No tak to pardon, ale jak souvisi ten vas priklad se zadanim (=revize)? Snad jen, ze tam mate sloupecek s nazvem aktualni, nad kterym provadite jakesi operace.

[Filip Jirsák]

Jednou z navrhovaných (a docela podporovaných) variant bylo mít jednotlivé revize dokumentu jako jednotlivé řádky v relační databázi. S tím, že aktuální revize bude mít nastaven příznak na true, ostatní na false. Moje námitka byla, že označovat aktuální verzi boolean příznakem v tabulce se mi nezdá vhodné - jednak to odporuje logice věci, druhak běžnými prostředky není možné kontrolovat referenční integritu, a za třetí se bude muset ještě speciálně hlídat zamykání této tabulky.

Hezký příklad spoléhání na to, že transakce v SQL vše vyřeší, je popsán ve spotu Příkaz SELECT a transakce aneb další lekce z naivity na blog.vyvojar.cz. Vše fungovalo jak má, až jednoho dne nastala situace, kdy došlo k současnému spuštění tří různých úloh v rozmezí několika milisekund.

[Filip Jirsák]

Píšu jenom první poznámky, v nějakou rozumnou denní dobu se nad tím zamyslím víc

Aby hibernate viděla vše, včetně revizí, to není problém - namapuje se i sloupeček s revizí. Aby viděla jen aktuální stav, musel by se zřejmě použít nějaký view na straně databáze.

SQL dotazy by neměl být problém rozšířit o podmínku, o kterou revizi se zajímám. Aktuální verze je pak specíální případ této podmínky - zjistím nejnovější revizi a tu dosadím do předchozí podmínky (v SQL vnořený SELECT).

Varianta s booleanem pro aktuální revizi je sice možná, ale musela by se ošetřit nějakými triggery, jinak hrozí nekonzistence databáze. A obecně informace o tom, která revize je nejnovější, mi dává třeba MAX(revize) (pokud je revize vzestupně číslovaná) - a ukládat do databáze redundantní informaci mi nepřipadá nejlepší.

Jako největší problém bych viděl, jak se má chovat strom objektů v souvislosti s revizemi. Pokud změním A.x, mění se tím revize objektu A - a mění se tím i revize A.z? Naopak, pokud změním A.z.x, mění se tím revize objektu A.z - mění se tím i revize objektu A?

Popíšu ten strom objektů v relačním pojetí. Dejme tomu, že mám záznam A, jedna z jeho položek je id odkazující na záznam B. Součástí toho id může být revize a nemusí. Třeba faktura a adresa - faktura odkazuje na adresu. Může odkazovat buď na id adresy, přičemž adresa samotná může mít několik revizí, ale ve faktuře použiju třeba vždy tu aktuální. Nebo můžu z faktury odkazovat na konkrétní revizi adresy - a když adresu opravím, na faktuře zůstane původní. Ono objektové schéma má ještě další možnost (v relačním trochu krkolomnou) - změním adresu, tím se mi de facto změní i faktura, takže bych měl vytvořit novou revizi i pro fakturu.

Další otázkou taky je, zda "strom objektů" má v relační databázi nějakou přirozenou interpretaci. Pokud ne, může být dodělání revizí už docela oříšek a možná by se vyplatilo poohlédnout se po nějaké objektové databázi nebo třeba XML databázi - i když to ani jedno samo o sobě neřeší problém revizí, může pro některý konkrétní případ být pro takový způsob reprezentace mnohem snazší přidat revize.

Celou dobu jsem předpokládal jen lineární revize, tj pouze vztah starší/novější. Revize ale také můžou být dělány způsobem rodič/potomek, kdy z jedné verze mohou vzniknout dvě a více samostatných nových verzí (můžeme to nazývat větvení, fork, branch...) V takovém případě ani nelze říci, co je aktuální verze, protože verze vytvářejí vlastně strom a aktuální verze jsou všechny jeho listy. Jediná možnost, jak v takovém případě určit, co je aktuální, je některý z listů vybrat a označit ho za aktuální. Tenhle koncept je možné zase rozšířit, můžu mít aktuální prvek pro každou větev. Může to vypadat, že koncept větvení revizí je už příliš složitý, ale prakticky veškerý vývoj softwaru používá tuhle metodu - v jedné větvi se udržuje stabilní verze, v druhé jsou betaverze, v další třeba technologické preview, ve větvi odštěpené z betaverze se vyvíjí samostatná nová funkce... Vlastně jediný mně známý rozšířený případ lineárního verzování je princip Wiki a různá workflow nebo verzované dokumenty. Takže je docela reálné, že z původního požadavku na lineární verzování vznikne brzy požadavek na verzování větvené, ale jeho implementace bude myslím velmi odlišná...

Uff, nemělo by Abíčko kontrolovat, aby zápisek v diskuzi nebyl delší než původní zápiske v blogu? Někteří lidi jsou strašní grafomani...

[Leoš Literák]

Ad SQL a posledni revize: pomoci tech vnorenych SQL dotazu asi bude mozne specifikovat, ze me zajimaji jen tahle data a z nich jen posledni revize. Akorat si takovy dotaz nedovedu moc predstavit. V mysql jsem vnorene dotazy nemel, takze jsem se je nemel kde naucit

Je to takhle nejak?

select * from A aa where x>3 and revize=(select max(revize) from A where id=aa.id)

Ad boolean: uvazoval jsem o transakci, kdy se vlozi novy radek s novou revizi a hned pote se updatene posledni revize a odejme se ten priznak. Nicmene trigger je take reseni.

Ad strom objektu: to je prave tema, ktere jsem v teto diskusi nechtel moc otevirat. Sam v tom nemam zatim moc jasno

Ad vetveni verzovani: brrr Ja chci jen prosty wiki styl, takze aby uzivatel videl, jakymi zmenami dany objekt(y) postupne prosel. Tudiz linearne.

[Filip Jirsák]

Vnořený dotaz je tak nějak, ono se to píše různě podle toho, co všechno mezi těmi dotazy potřebuju přenášet. A stejně je to záležitost každého databázového stroje, co umí, takže by se to muselo dohledat v dokumentaci. Aspoň já si tedy nepamatuju ani jendu formu zápisu vnořeného selectu

Ad boolean - popisoval jsem to o něco výš - obecně databáze vidí v průběhu transakce databázi v takovém stavu, v jakém byla před začátkem transakce. V tomhle případě by tedy mohly vzniknout 2 a více aktuálních verzí.

[podlesh]

Jak tak koukám, hlavní problém u řešení s jednou tabulkou je, že potřebuji většinou jen poslední revizi a nevím která to je. Na první pohled patrná řešení s pomocným sloupcem bool last_revision a s použitím subselektu jsou docela nepraktická. Proto bych navrhoval jiný fígl. Lze ovšem použít jen pokud samotné číslo revize není důležitý (a všude zobrazovaný) údaj.

Proč by mapování čísla revize muselo být přímé? Prostě místo pravého aktuálního čísla revize bude 0. Starší revize budou mít čísla pravá (1,2,...).

Vytažení všech aktuálních objektů: SELECT ... FROM ... WHERE revision=0 AND ... Zde je právě ten problém, že ve výsledku nebudou k dispozici čísla revizí.

Získání skutečného čísla revize: SELECT max(revision)+1 FROM ... WHERE ...

Vytvoření nové revize bude prostě zkopírování aktuálního záznamu pod novým číslem revize (INSERT).

[Martin Beránek]

Za předpokladu že se využije hibernate:

Nacpal bych to všechno do jedne tabulky. Objektově bych udělal lineární závislost naprosto přirozeně: rodič - potomek, jenom s tím že nyní ukazuje rodič na potomka. Vyhledáni všech aktualních záznamů, je tedy najití všech, kteří mají nastavený ukazatel na null. Výkonost by to chtělo otestovat, ale věřím že by to mělo šlapat vcelku rychle.

select * from clanky where child is null;

[Martin Beránek]

Mě se při práci s Hibernate osvědčil postup HBM->Java, jak to děláte vy?

ještě sem narazil na tohle.

[Leoš Literák]

zajimave linky: Simple Versioning of Database Entries, versioning via logging