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

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.

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.

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

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

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.

A post-hooks?

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.

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.

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.