Hibernate: hbm2ddl.auto = aktualizacja w produkcji?

Robimy to w produkcji, choć z aplikacją, która nie jest krytyczna dla misji i bez wysoko płatnych dba na personel. To tylko jeden proces ręczny mniej, który podlega błędowi ludzkiemu - aplikacja może wykryć różnicę i zrobić właściwą rzecz, a ponadto prawdopodobnie przetestowałeś go w różnych środowiskach programistycznych i testowych.

Jedno zastrzeżenie - w środowisku klastrowym możesz tego uniknąć, ponieważ wiele aplikacji może pojawić się w tym samym czasie i spróbować zmodyfikować schemat, który może być źle. Lub umieścić w jakimś mechanizmie, w którym tylko jedna instancja może aktualizować schemat.

Twórcy Hibernate zniechęcają do tego w środowisku produkcyjnym w swojej książce "Java Persistence with Hibernate":

Ostrzeżenie: widzieliśmy użytkowników Hibernate próbujących użyć SchemaUpdate do automatycznej aktualizacji schematu produkcyjnej bazy danych. Może to szybko skończyć się katastrofą i nie będzie dozwolone przez twój DBA.

Sprawdź LIQUIBASE XML, aby przechowywać changelog aktualizacji. Nigdy nie używałem go aż do tego roku, ale odkryłem, że jest bardzo łatwy do nauczenia się i sprawia, że kontrola wersji DB/migracja/zarządzanie zmianami jest bardzo niezawodna. Pracuję nad projektem Groovy / Grails, a Grails używa Hibernate pod spodem dla wszystkich swoich ORM (zwanych "GORM"). Używamy Liquibase do zarządzania wszystkimi zmianami w schemacie SQL, co robimy dość często, gdy nasza aplikacja ewoluuje wraz z nowymi funkcjami.

Zasadniczo zachowujesz plik XML z zestawami zmian które nadal dodajesz w miarę rozwoju aplikacji. Ten plik jest przechowywany w git (lub czymkolwiek używasz) wraz z resztą twojego projektu. Po wdrożeniu aplikacji Liquibase sprawdza listę zmian w bazie danych, z którą się łączysz, aby wiedzieć, co zostało już zastosowane, a następnie inteligentnie stosuje te zestawy zmian, które nie zostały jeszcze zastosowane z pliku. To działa absolutnie świetnie w praktyce, i jeśli używasz go dla wszystkich zmian schematu, a następnie można być 100% pewność, że kod, który realizujesz i wdrażasz, zawsze będzie w stanie połączyć się z w pełni kompatybilnym schematem bazy danych.

Niesamowite jest to, że mogę wziąć całkowicie pustą bazę danych mysql na moim laptopie, odpalić aplikację i od razu schemat jest skonfigurowany dla mnie. Ułatwia również testowanie zmian schematu, stosując je najpierw do lokalnego dev lub staging db.

Najprostszym sposobem na rozpoczęcie pracy z nim byłoby prawdopodobnie pobranie istniejącego DB, a następnie użycie Liquibase do Wygeneruj początkową linię bazową.plik xml. Następnie w przyszłości możesz po prostu dołączyć do niego i pozwolić liquibase przejąć zarządzanie zmianami schematu.

Http://www.liquibase.org/

Głosowałbym na nie. Hibernate zdaje się nie rozumieć, kiedy zmieniły się typy danych dla kolumn. Przykłady (za pomocą MySQL):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)

@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

Prawdopodobnie istnieją również inne przykłady, takie jak przesunięcie długości kolumny łańcuchowej o ponad 255 i zobaczenie jej konwersji na tekst, mediumtext itp.

Przyznaję, nie sądzę, że istnieje sposób na "konwersję typów danych" bez tworzenia nowej kolumny, kopiowania danych i zdmuchiwania starej kolumny. Ale w chwili gdy twoja baza danych ma kolumny, które nie odzwierciedlają bieżącego mapowania Hibernate żyjesz bardzo niebezpiecznie...

Flyway jest dobrym rozwiązaniem, aby poradzić sobie z tym problemem:

Http://flywaydb.org

Hibernate musi umieścić zastrzeżenie o nie używaniu automatycznych aktualizacji w prod, aby pokryć się, gdy ludzie, którzy nie wiedzą, co robią, używają go w sytuacjach, w których nie powinien być używany.

Przyznane sytuacje, w których nie powinien być używany znacznie przewyższają te, w których jest OK.

Używam go od lat w wielu różnych projektach i nigdy nie miałem ani jednego problemu. To nie jest kiepska odpowiedź, i to nie jest kowbojskie kodowanie. To historyczny fakt.

Osoba kto mówi "nigdy nie rób tego w produkcji", myśli o konkretnym zestawie wdrożeń produkcyjnych, a mianowicie o tych, z którymi jest zaznajomiony (jego firma, jego branża itp.).

Wszechświat "wdrożeń produkcyjnych" jest ogromny i zróżnicowany.

Doświadczony programista Hibernate wie dokładnie, co DDL będzie wynikało z danej konfiguracji mapowania. Tak długo, jak testujesz i sprawdzasz, czy to, czego oczekujesz, kończy się w DDL (w dev, qa, staging itp.), jesteś w porządku.

Kiedy dodawanie wielu funkcji, Automatyczne aktualizacje schematu mogą być oszczędność czasu.

Lista rzeczy, które auto updates nie obsłuży jest nieskończona, ale niektóre przykłady to migracja danych, dodawanie nie nullable kolumn, zmiany nazw kolumn, itp, itd.

Również trzeba dbać w środowiskach klastrowych.

Ale z drugiej strony, gdybyś wiedział o tym wszystkim, nie zadawałbyś tego pytania. Hmm . . . OK, jeśli zadajesz to pytanie, powinieneś poczekać, aż będziesz miał duże doświadczenie z aktualizacjami Hibernate i auto schema, zanim pomyślisz o użyciu go w prod.

Jak wyjaśniłem w w tym artykule , nie jest dobrym pomysłem używanie hbm2ddl.auto w produkcji.

Jedynym sposobem zarządzania schematem bazy danych jest użycie skryptów migracji przyrostowej, ponieważ:

• skrypty będą znajdować się w VCS wzdłuż bazy kodu. Kiedy kasujesz gałąź, odtwarzasz cały schemat od zera.
• Skrypty przyrostowe mogą być testowane na serwerze QA przed zastosowaniem ich w produkcji
• nie ma potrzeby ręcznej interwencji ponieważ skrypty mogą być uruchamiane przez Flyway , zmniejsza to możliwość wystąpienia błędu ludzkiego związanego z ręcznym uruchamianiem skryptów.

Nawet Podręcznik Użytkownika Hibernate radzi, aby unikać używania narzędzia hbm2ddl w środowiskach produkcyjnych.

Robimy to w projekcie działającym w produkcji od miesięcy i do tej pory nie mieliśmy żadnego problemu. Należy pamiętać o 2 składniki potrzebne do tego przepisu:

1. Zaprojektuj swój model obiektowy z podejściem wstecznej zgodności, to znaczy deprecate obiektów i atrybutów zamiast usuwania/zmieniania ich. Oznacza to, że jeśli chcesz zmienić nazwę obiektu lub atrybutu, zostaw Stary taki, jaki jest, Dodaj nowy i napisz jakiś skrypt migracji. Jeśli potrzebujesz aby zmienić skojarzenie między obiektami, jeśli już jesteś w produkcji, oznacza to, że twój projekt był w pierwszej kolejności niewłaściwy, więc spróbuj wymyślić nowy sposób wyrażania nowej relacji, bez wpływu na stare dane.

2. Zawsze Wykonaj kopię zapasową bazy danych przed wdrożeniem.

Moim zdaniem - po przeczytaniu tego postu-90% osób biorących udział w tej dyskusji jest przerażonych samą myślą o użyciu takich automatów w środowisko produkcyjne. Niektórzy rzucają piłkę w DBA. Poświęć chwilę, aby wziąć pod uwagę, że nie wszystkie środowiska produkcyjne zapewnią DBA i niewiele zespołów programistów jest w stanie sobie na to pozwolić (przynajmniej w przypadku średnich projektów). Więc jeśli mówimy o drużynach, w których każdy musi robić wszystko, piłka jest na nich.

W tym przypadku, dlaczego po prostu nie spróbować mieć najlepsze z obu światów? Narzędzia takie jak ten są tutaj, aby podać pomocną dłoń , która-przy starannym projektowaniu i planowaniu - może pomóc w wielu sytuacjach. I uwierz mi, administratorzy początkowo mogą być trudne do przekonania, ale jeśli wiedzą, że piłka nie jest na ich rękach, pokochają ją.

Osobiście nigdy nie wróciłbym do ręcznego pisania skryptów do rozszerzania jakiegokolwiek schematu, ale to tylko moje zdanie. I po tym, jak ostatnio zacząłem przyjmować bazy danych bez schematów NoSQL, widzę, że więcej niż wkrótce, wszystkie te operacje oparte na schemacie będą należeć do przeszłości, więc lepiej zacznij zmieniać swoje perspektywa i spojrzenie w przyszłość.

Nie zaryzykowałbym, ponieważ może skończyć się utratą danych, które powinny być zachowane. hbm2ddl.auto = update to prosty sposób na aktualizację bazy dev.

• W moim przypadku (Hibernate 3.5.2, Postgresql, Ubuntu), ustawienie hibernate.hbm2ddl.auto=update tworzy tylko nowe tabele i tworzy nowe kolumny w już istniejących tabelach.

• Nie upuszczał tabel, nie upuszczał kolumn, nie zmieniał kolumn. Można ją nazwać bezpieczną opcją, ale coś w rodzaju hibernate.hbm2ddl.auto=create_tables add_columns byłoby bardziej jasne.

Nie, nigdy tego nie rób. Hibernate nie obsługuje migracji danych. Tak, sprawi, że twój schemat będzie wyglądał poprawnie, ale nie zapewnia, że cenne dane produkcyjne nie zostaną utracone w procesie.

To niebezpieczne, nie zalecane, ale możliwe.

Mam doświadczenie w aplikacji wykorzystującej opcję auto-update w produkcji.

Cóż, główne problemy i zagrożenia występujące w tym rozwiązaniu to:

• wdrożyć w niewłaściwej bazie danych . Jeśli popełnisz błąd, aby uruchomić serwer aplikacji ze starą wersją aplikacji (EAR / WAR / etc) w niewłaściwej bazie danych... Będziesz miał wiele nowych kolumn, tabel, kluczy obcych i błędów. Ten sam problem może wystąpić z prostym błędem w pliku datasource, (skopiuj/wklej plik i zapomniałeś zmienić bazę danych). W CV sytuacja może być katastrofą w Twojej bazie danych.
• uruchomienie serwera aplikacji trwa zbyt długo . Dzieje się tak, ponieważ Hibernate próbuje znaleźć wszystkie utworzone tabele/kolumny/etc przy każdym uruchomieniu aplikacji. Robi to, aby wiedzieć, co (tabelę, kolumnę itp.) należy utworzyć. Ten problem tylko się pogorszy.
• Narzędzia bazy danych to prawie niemożliwe do użycia . Aby utworzyć skrypty dla bazy danych, musisz pomyśleć o tym, co zostanie utworzone przez automatyczną aktualizację po uruchomieniu serwera aplikacji. Jeśli chcesz wypełnić nową kolumnę (na przykład) danymi, musisz uruchomić serwer aplikacji, poczekać na hibernację nowej kolumny i następnie uruchomić skrypt SQL. Narzędzia takie jak Flyway korzystanie z automatycznej aktualizacji jest prawie niemożliwe.
• zmiany w Bazie Danych nie są scentralizowane . Z możliwością z Hibernate tworzenie tabel i wszystko inne, trudno obserwować zmiany w bazie danych w każdej wersji aplikacji, ponieważ większość z nich są automatycznie.
• zachęca do śmieci w bazie danych . Ze względu na łatwość automatycznej aktualizacji, istnieje szansa, że twój zespół zaniedbuje opuszczanie starych kolumn i starych tabel.
• nieuchronna katastrofa . Bezpośrednie ryzyko wystąpienia jakiejś katastrofy w produkcji (jak niektórzy ludzie wspomniani w innych odpowiedziach). Nawet z aplikacja działająca i aktualizowana od lat, nie sądzę, że jest Bezpieczna. Nigdy nie czułam się Bezpieczna.

Dlatego nie polecam używania automatycznej aktualizacji w produkcji.

Jeśli naprawdę chcesz użyć auto-update w produkcji, polecam:

• sieci rozdzielone . Środowisko testowe nie może uzyskać dostępu do środowiska homolog. Pomaga to zapobiec wdrożeniu, które miało być w środowisku testowym, zmianie bazy danych homologacji.
• Zarządzaj kolejność skryptów . Musisz zorganizować skrypty do uruchomienia przed wdrożeniem (zmiana tabeli struktury, upuść tabelę/kolumny) i skrypt po wdrożeniu (wypełnij informacje o nowych kolumnach/tabelach).

I, różni się od innych postów, Nie sądzę, aby włączona automatyczna aktualizacja była związana z" bardzo dobrze płatnymi " DBAs (jak wspomniano w innych postach)... Bazy danych mają ważniejsze rzeczy do zrobienia niż pisanie poleceń SQL, aby tworzyć/zmieniać / usuwać tabele i kolumny. Te proste codzienne zadania mogą być wykonywane i zautomatyzowane przez programistów i przekazywane tylko zespołowi DBA do przeglądu, nie potrzebującemu Hibernate i DBAs "bardzo dobrze płatnych", aby je napisać.

• Zazwyczaj aplikacje korporacyjne w dużych organizacjach działają z ograniczonymi uprawnieniami.

• Nazwa użytkownika bazy danych może nie mieć DDL uprawnień do dodawania kolumn, których wymaga hbm2ddl.auto=update.

Zgadzam się z Vladimirem. Administratorzy w mojej firmie na pewno nie docenią tego, gdybym w ogóle zasugerował taki kurs.

Ponadto, stworzenie skryptu SQL zamiast ślepo ufającego Hibernate daje możliwość usunięcia pól, które nie są już używane. Hibernate tego nie robi.

I uważam, że porównanie schematu produkcji z nowym schematem daje jeszcze lepszy wgląd w to, co zmieniłeś w modelu danych. Wiesz, oczywiście, ponieważ udało Ci się, ale teraz widzisz wszystkie zmiany za jednym zamachem. Nawet te, które sprawiają, że mówisz " co do cholery?!".

Istnieją narzędzia, które mogą zrobić delta schematu dla ciebie, więc nie jest to nawet ciężka praca. I wtedy wiesz dokładnie, co się stanie.

Schemat aplikacji może ewoluować w czasie; jeśli masz kilka instalacji, które mogą być w różnych wersjach, powinieneś mieć jakiś sposób, aby upewnić się, że aplikacja, jakieś narzędzie lub skrypt są w stanie przenieść schemat i dane z jednej wersji krok po kroku do dowolnej następnej.

Posiadanie całej swojej trwałości w mapowaniach Hibernate (lub adnotacjach) jest bardzo dobrym sposobem na kontrolowanie ewolucji schematu.

Należy wziąć pod uwagę, że ewolucja schematu ma kilka aspekty, które należy wziąć pod uwagę:

1. Ewolucja schematu bazy danych w dodawanie kolejnych kolumn i tabel

2. Zrzucanie starych kolumn, tabel i relacje

3. Wypełnianie nowych kolumn wartościami domyślnymi

Narzędzia Hibernate są szczególnie ważne w przypadku, gdy (jak z mojego doświadczenia) masz różne wersje tej samej aplikacji na wielu różnych rodzajach baz danych.

Punkt 3 jest bardzo wrażliwy w przypadku, gdy używasz Hibernate, tak jak w przypadku wprowadzenia nowej wartości logicznej lub numerycznej, jeśli Hibernate znajdzie dowolną wartość null w takich kolumnach, jeśli wywoła wyjątek.

Więc co bym zrobił, to: rzeczywiście używać możliwości Hibernate narzędzia aktualizacji schematu, ale trzeba dodać obok niego niektóre dane i wywołania zwrotnego konserwacji schematu, jak do wypełniania domyślnych, upuszczanie nie używane kolumny, i podobne. W ten sposób uzyskasz korzyści (niezależne od bazy danych Skrypty aktualizacji schematu i unikanie zduplikowane kodowanie aktualizacji, w perystencji i w skryptach), ale obejmuje również wszystkie aspekty operacji.

Więc na przykład, jeśli aktualizacja wersji polega po prostu na dodaniu właściwości o wartości VARCHAR (stąd kolumna), która może domyślnie mieć wartość null, z automatyczną aktualizacją będziesz gotowy. Tam, gdzie konieczna jest większa złożoność, konieczne będzie więcej pracy.

Zakłada się, że aplikacja po aktualizacji jest w stanie zaktualizować swój schemat( można to zrobić), co oznacza również, że musi mieć prawa użytkownika, aby to zrobić na schemacie. Jeśli polityka klienta temu uniemożliwia (prawdopodobnie przypadek Lizard Brain), będziesz musiał podać Skrypty specyficzne dla bazy danych.