SVN i MySQL Opcje

[shakal69]

Witam,

Czy macie jakiś sposób na powiązanie zmian wersji ze zmianami struktury bazy danych.

Chodzi o to że mamy witrynę która jest aktualizowana przez SVN i chciałbym zrobić tak aby uaktualnienie dotyczyły także struktury bazy danych.
Wprowadzamy zmiany w kodzie w wersji roboczej zmieniamy strukturę danych, testujemy i commitujemy.
Uaktualniamy wersje produkcyjną na serwerze i tu chodzi aby od razu dokonać aktualizacji bazy danych.

Teraz załóżmy, że wykrywamy w aplikacji błąd krytyczny którego usunięcie zajmie nam sporo czasu i musimy przywrócić poprzednią wersję serwisu.


Czy jest jakieś rozwiązanie połączenia synchronizacji kodu i bazy danych (IMG:style_emoticons/default/questionmark.gif)

[erix]

Najczęsciej widywałem po prostu eksport struktury SQL w pliku tekstowym, zwykłe altery w porównaniu do poprzedniego brancha.

A dumpy chyba warto trzymać gdzieś w osobnym miejscu, jako kopia zapasowa. Tylko nigdy nie wrzucaj do SVN-a. Znam sytuację, w której ktoś wrzucił 3 GiB plik SQL do repozytorium. (IMG:style_emoticons/default/biggrin.gif)

[zwierzołak]

Muszę przyznać, że też mi chodzi ten temat po głowie. Wydaje się, że robienie eksportu struktury do pliku SQL (sam tak robię na razie) to niezbyt dobre rozwiązanie, bo trzeba o tym pamiętać za każdym razem. Jak zrobimy commita, albo 'check for modifications', to zmiana w bazie nie pojawi się na liście zmian.

Musi być jakaś bardziej profesjonalna metoda. Np mógłby być to skrypt uruchamiany automatycznie przed każdym commitem i eksportujący strukturę bazy do odpowiedniego pliku sql - wtedy zmiany w strukturze bazy automatycznie pokażą się za każdym razem i będą uwzględnione w repozytorium.

[shakal69]

Witam,

Musi być jakieś inne rozwiązanie. Może jakiś skrypt monitorujący wysyłane polecenia do bazy w czasie aktualizacji i tworzący jakiś plik w rodzaju diff.

Przywracanie bazy z dumpa może i jest dobre, ale jeśli stronę edytuje tylko admin. Natomiast jeśli mamy forum lub sklep internetowy przywrócenie dumpa nie wchodzi w grę. Ponieważ w między czasie użytkownicy dokonują zmian w bazie.

Może się ktoś wypowie jak to jest rozwiązane w firmach które mają np autorskie cms lub sklepy internetowe.

Można by to zrobić przez zrzucenie dwa razy bazy dumpem. Raz przed zmianą struktury i drugi raz po zmianie i wykonać porównanie plików
diff -u db.sql db2.sql | less

ale jeśli mamy duże bazy po klika gb to jest to praktycznie nie wykonalne.
Zresztą otrzymujemy plik tylko z różnicami to co zostało dodane do bazy lub usunięte, żeby utworzyć plik do downgradeu i tak musimy go ręcznie przerabiać, a następnie dodawać gdzieś do SVN, no i nie jest to automatyczne

[Mchl]

mysqldump może zrobić Ci tylko zrzut struktury bez danych.

[morgan]

W tym przypadku svn nie pomoże, trzeba użyć jakiegoś systemu migracji, np w ror jest od dawna. W orm doctrine też jest zaimplementowany system migracji. Takze mozna korzystac z doctrine, a jak nie to przynajmniej zobaczyć jak to działa i wyciągnać wnioski :]

Dodam jeszcze, że w doctrine ten system mi się bardzo podoba i naprawdę polecam przynajmniej wypróbować, w użyciu jest bardzo podobny do tego z railsa.

Ten post edytował morgan 1.04.2010, 14:57:36

[erix]

Musi być jakaś bardziej profesjonalna metoda. Np mógłby być to skrypt uruchamiany automatycznie przed każdym commitem

A post-hooks?

[Zyx]

Rozwiązanie to dobry ORM, np. Doctrine. Schemat bazy przechowywany jest w postaci pliku YAML, do tego mamy zestaw danych początkowych. Po każdym update odpalamy interfejs konsolowy Doctrine z poleceniem build-all-reload i mamy wgraną najświeższą wersję bazy.

Alternatywne rozwiązanie to przechowywanie plików MySQL Workbench, który też posiada synchronizację schematu z bazą, tyle że te pliki są skompresowane i przez to ciężko je składować sensownie w repozytorium. Być może jest gdzieś w programie opcja generowania plików nieskompresowanych (mają one wtedy postać dokumentu XML), ale nie przyglądałem się temu.

[dr_bonzo]

Polecam cos na wzor migracji w Railsach, Doctrine chyba cos podobnego ma.

U nas tworzymy przyrostowe pliki SQL (recznie: robie zmiany w PMA - on generuje mi SQLke - kopiuje do pliku i juz).
Tak samo ze wstecznymi migracjami tez recznie (nie jest to duzo roboty).

Potem odpalamy "instalator" na produkcyjnym, ktory zaktualizuje baze.

Nie koniecznie musi byc to robione przez hooki svn'a.

[magnus]

Doctrine i migracje. Po zmianie struktury bazy tworzy się (automatycznie wg zmienionej definicji) plik migracji, który potem umożliwia aktualizację bazy w obie strony (przejście na nowszą strukturę kiedy mamy starszą oraz powrót do wcześniejszej gdy trzeba).
Trzeba trochę czasu poświęcić, żeby to opanować ale jest dość wygodne.