Jak verzovat databázi? rubrika: Programování: PHP

5 Filip Halaxa
položil/-a 2.6.2012

Způsobů je víc. Zajímalo by mě, co se osvědčuje v praxi. Díky.

odkaz
7 vaclavnovotny
odpověděl/-a 8.6.2012

Verzování databáze je z mých zkušeností dlouhodobě těžko řešitelný problém, ale něco málo se v tomto ohledu dá přeci jenom udělat.

Na současném projektu používáme balík Doctrine migrations. Projekt vyvíjíme nad Symfony 2 spolu s Doctrine 2, což zaručuje jeho snadné použití, nicméně balík se dá použít i samostatně (https://github.com/doctrine/migrations - pouze se zdá, že mají aktuálně nějaký problém s dokumentací).

V principu funguje tak, že píšete jednotlivé migrace, což jsou PHP třídy, které mají vždy metodu up a down. Metoda up slouží pro migraci dopředu, metoda down pro vrácení změny zpět. To, v jaké verzi máme databázi, zajišťují záznamy v jedné databázové tabulce (konkrétně nese název migration_versions).

Princip je to tedy jednoduchý a funkční. Nicméně stále platí, že ani tento systém nás nezachrání, pokud budeme psát SQL změny nekompatibilně a nebezpečně.

Komentáře

  • Filip Halaxa : Díky, to zní zajímavě. Měl jsem na mysli nějaký zautomatizovaný systém, který by mi umožňoval mít aktuální schéma v repozitáři společně s aplikací. V repu bych měl něco jako schema.sql a v každém commitu by odráželo kompatibilní stav k aplikaci. Třeba by to mohlo být zajištěno dumpem uvnitř nějakého pre-commit hooku. Líbilo by se mi, aby to bylo nezávislé na konkrétní technologii (Doctrine). 8.6.2012
  • Taco : Tak to by ten schema-manage mohl splňovat. 9.10.2012
  • bretislav.wajtr : Take se priklanim k reseni migracnich souboru, jenom bych doplnil par pravidel, ktere se nam v praxi osvedcily: 1. Pro kazdou zmenu jeden migracni soubor - i za cenu toho ze bude migracnich souboru mnoho 2. Krome up and down casti mit v migracnim souboru take informaci, jestli je zmena vratna nebo ne (tedy pokud se da vubec udelat down) - takove zmeny existuji (tzv. destruktivni zmeny) a s temi je vzdy ukrutny problem - je dobre o nich vedet 3. Migracni soubory necislovat nejakou sekvenci (1,2,3,4...) ale spise nejakym hashem. Spravny stav databaze by se pak mel oznacovat seznamem pozadovanych migracnich souboru a ne jenom jednim cislem (napr. required db version: 32). Proc? Protoze kdyz se vam vyvoj na trunku na branchi zacne ubirat znacne jinym smerem, mate pak problem s tim, ze jste na branchi vytvorili migracni script 32, ktery uz ale na trunku take nekdo vytvoril, akorat s jinym obsahem. A co ted, ze :). Snad to nekomu pomohlo... 12.10.2012
  • tomas.fejfar : bretislav.wajtr: Správné řešení je prefixovat migrace timestampem (tak to dela ruckusing) - tam je šance na stejnou sekundu dostatečně malá. Hashem se nedá určit správné pořadí migrací. 19.10.2012
  • Taco : Jak budete řešit souběh dvou větví od dvou vývojářů? Je mi jasné, že díky timestapmu se zaklesnou do sebe. Ale V jakém stavu bude schema? Není to poněkud riskantní? 19.10.2012
  • tuma.vojta : Přidávám s k @Taco. Automaticky mergovat změny DB je hodně riskantní záležitost. Tohle je věc, kterou je lepší dělat ručně. A když máš právě 2 stejný čísla po merge na trunk, tak vidíš, co je přesně potřeba opravit a kde může vzniknout problém. Takže ručně upravíš řadu změn. 7.8.2014
  • tomas.fejfar : Šest let vývoje, tisíce changesetů, nikdy žádný problém. 10.8.2014

Pro zobrazení všech 13 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.