Chciałbym się dowiedzieć, jaki jest ogólny schemat postępowania gdy chcemy skorzystać z migracji na aktualnej bazie danych w środowisku produkcyjnym.
Baza zawiera już jakieś dane i np. potrzebujemy dodać kolumnę w tabeli. Gdyby baza była pusta, to sprawa jest łatwa i przyjemna, ale tutaj się komplikuje gdyż nie chciałbym stracić danych(tfu, nie mogę stracić danych).
Czy może ktoś polecić uniwersalny przepis na to, jak przed zrobieniem migracji skopiować gdzieś dane, zrobić migracje a później import tych danych?
Chciałbym się dowiedzieć, jaki jest ogólny schemat postępowania gdy chcemy skorzystać z migracji na aktualnej bazie danych w środowisku produkcyjnym.
Baza zawiera już jakieś dane i np. potrzebujemy dodać kolumnę w tabeli. Gdyby baza była pusta, to sprawa jest łatwa i przyjemna, ale tutaj się komplikuje gdyż nie chciałbym stracić danych(tfu, nie mogę stracić danych).
Czy może ktoś polecić uniwersalny przepis na to, jak przed zrobieniem migracji skopiować gdzieś dane, zrobić migracje a później import tych danych?[/quote]
Ale przy rake db:migrate nie tracisz danych. Moze sobie pomyliles z rake db:schema:load?
Tworzysz nową migracje, odpalasz rake db:migrate.
Jedynie co moze byc klopotliwe przy duzych bazach to import schematów wszystkich tabel do db/schema.rb - ktory dlugo trwa.
Proponuje przeprowadzic tez test na osobnej bazie, żeby poźniej nie było płaczu
Chciałbym się dowiedzieć, jaki jest ogólny schemat postępowania gdy chcemy skorzystać z migracji na aktualnej bazie danych w środowisku produkcyjnym.
Baza zawiera już jakieś dane i np. potrzebujemy dodać kolumnę w tabeli. Gdyby baza była pusta, to sprawa jest łatwa i przyjemna, ale tutaj się komplikuje gdyż nie chciałbym stracić danych(tfu, nie mogę stracić danych).
Czy może ktoś polecić uniwersalny przepis na to, jak przed zrobieniem migracji skopiować gdzieś dane, zrobić migracje a później import tych danych?[/quote]
Ale przy rake db:migrate[/quote]
Przecież jak zrobie migrate do wersji 0 to robi drop tabeli
Ah, no musze zjechać w dół bo mam tak, że dla każdego modelu mam osobną migracje która odpowiada za całą tabele. Zmiana w takiej tabeli musi odbyć się w pliku migracji który już istnieje.
Nie rozumiem co mają do tego źle napisane migracje? To normalne że w trakcie życia aplikacji może się zmienić nazwa kolumny w tabeli lub będzie trzeba dodać nową kolumnę. Gdybym za każdym razem miał tworzyć do tego osobny plik z migracją, to miałbym bałagan.
do każdego modelu chce mieć 1 plik z migracją
w momencie zmiany/dodania kolumny, muszę zrobić migrate do revision 0 ale nie chce stracić danych w bazie.
Pytanie: jak się to robi? Zamiast tych przepychanek, proszę podaj mi jakieś wskazówki bo jak narazie nic nie wnosi to do mojego wątku.
PS. Powżysze narzędzie do którego wysłałem link jest dobre do robienia backupu, ale nie radzi sobie gdy zmieni się schemat bazy.
Według mnie dobrym rozwiązaniem jest: w etapie development stosować zasadę jedne plik = jedna tabela. a od czasu uruchomienia aplikacji “na produkcji” stosować migracje przyrostowe.
Co do etapu developmentu to stworzyłem taska, który migruje bazy do wersji 0, wykonuje migracje do aktualnej wersji i wczytuje dane do bazy development z plików csv. To rozwiązanie ma zalety w przypadku, gdy jest kilku developerów i każdy ma swoją bazę developerską(dane, na których developerzy pracują są zsynchronizowane).
Poza tym proponuje ZAWSZE zrobić zrzut bazy przed jakąkolwiek modyfikacją schematu na serwerze produkcyjnym. Niezależnie od technologii.
Po to aby mieć porządek. Zresztą nie jest to istotne, dla osób które mają więcej plików migracji też będą potrzebowały ładnego rozwiązania
na nie tracenie danych przy migracji w dół.
Dlaczego do wersji 0?
Uzywales wczesniej migracji?[/quote]
Np dlatego, że muszę zrobić zmiany w pliku 001_?
Zyllion, z tego co piszesz to chcesz używać mechanizmu migracji w niekonwencjonalny sposób, tzn. mieć 1 plik migracji dla modelu:
Do tego właśnie został stworzony mechanizm migracji, dodajesz nową kolumnę to tworzysz nowy plik migracji i zmieniasz schemat bazy. Dzięki temu, że twój schemat ma przypisaną wersję możesz wrócić do jakiejś konkretnej wersji (np. cofnąć zmiany), możesz też cały czas “iść w górę”.
Co rozumiesz przez bałagan ? Dla przykładu aplikacja nad którą pracuję ma w db/migrations/ około 90 plików, które pokazują mi dokładnie jak ewoluował schemat bazy, aktualny schemat zawsze widać w schema.rb albo w poszczególnych modelach jeśli korzystasz z pluginu annotate_models, wszystko jest widoczne.
Napisz więcej o powodach dla których nie chcesz korzystać z wersji w migracjach, ponieważ tego co chcesz (1 wersja dla modelu + każdy model w oddzielnym pliku ) nie da się łatwo zrobić (bez napisania swojego mechanizmu migracji ponieważ numer wersji odnośi się do całego schematu bazy a nie do oddzielnych tabel).
BTW. Backup bazy danych przed każdym releasem to dobry pomysł tak czy inaczej, proponuję napisać swojego task’a do Capistrano i wywoływać go przed deploy:migrate
Podejrzewam, że nie masz na myśli rake db:migrate VERSION=15 ?
Alternatywą jest trzymanie w bazie db/schema.rb i polecenie rake db:schema:load
Nie będą potrzebowały, bo na serwerze produkcyjnym nie migruje się w dół. Po prostu używasz migracji w zły sposób. Świadczy o tym chęć modyfikowania 001…
Jak pisał piachoo, to jest akcepowalne na etapie developerki, ale nie jak się wypuszcza jakąś wersję produkcyjną.
A co do rozwiązania Twojego problemu, to możesz zrobić zrzut do sql, przenieść go do innej bazy i po zmianach napisać jakiegoś rake taska, który Ci przeniesie dane ze starej do nowej. Choć to dość upierdliwe.
Albo napisać nowe migracje, opierające się na schemacie bazy na serwerze produkcyjnym.
[quote=Zyllion]Po to aby mieć porządek. Zresztą nie jest to istotne, dla osób które mają więcej plików migracji też będą potrzebowały ładnego rozwiązania na nie tracenie danych przy migracji w dół.
Nie będą potrzebowały, bo na serwerze produkcyjnym nie migruje się w dół. Po prostu używasz migracji w zły sposób. Świadczy o tym chęć modyfikowania 001…
Jak pisał piachoo, to jest akcepowalne na etapie developerki, ale nie jak się wypuszcza jakąś wersję produkcyjną.[/quote]
Dzięki tak będe robił
Rozumiem, że chodzi Ci o to, że tworzysz migrację odpowiadającą za utworzenie tabeli np. users (tworzony jest blik 001_…). W tej tabeli masz np. pole name typu string. Następnie po jakimś czasie (i stworzeniu już 10 kolejnych tabel poprzez migrację) stwierdzasz, że w tabeli users powinno być pole first_name i last_name typu string zamiast name. W takim przypadku nie cofasz się z zmianami do wersji pierwszej, tylko tworzysz kolejny plik migracji i modyfikujesz już stworzoną bazę danych.
Np.
