[mk321]

#programowanie #java #hibernate

Napisaliście aplikację, wdrożyliście ją i już działa. Na produkcji w bazie danych są jakieś dane.

Rozwijacie dalej aplikację i robicie jakieś zmiany w Entity (np. dodanie kolumny w bazie, zmiana nazwy tabeli).

Co robicie przy wdrożeniu?
1. Pozwalacie aby Hibernate sam sobie naniósł zmiany?
2. Używacie Liquibase i przygotowujecie odpowiedni changeset?
3. Używacie FlyBase i przygotowujecie odpowiedni changeset?
4. Ręcznie piszecie SQL-ki, żeby dostosować schemat bazy na produkcji?
5. Eksportujecie dane z bazy, pozwalacie, żeby Hibernate utworzył schemat bazy od nowa i importujecie stare dane?
6. Inne.

[g0dl1ke]

@mk321: 4. Ręcznie piszę SQL, ale czekam z tym do godziny 16 w piątek

[t.....y]

@mk321:

Ręcznie piszecie SQL-ki, żeby dostosować schemat bazy na produkcji?

[JacobTheLiar]

@mk321: Ręcznie, z reguły dostosowuję klienta (Hibernate) do bazy danych. Ewentualnie buduję odpowiedni view na potrzeby działania aplikacji lub stosuję Konwertery jak nie można inaczej.

no i używam spring.jpa.hibernate.ddl-auto=validate

[mk321]

@JacobTheLiar:

Jeśli chodzi o widoki:
1. Rozumiem, że zazwyczaj są to zwykłe view (tzn. na żywo odpytywanie innych tabel przez widok), a nie materialized view?
2. Nie masz problemów z wydajnością (zamiast odpytywać bezpośrednio tabelę to taki widok pod spodem musi robić np. joiny)?
3. Widoków używasz tylko do odczytywania danych? A co z update? Przez widoki chyba nie da się prosto

[mk321]

no i używam spring.jpa.hibernate.ddl-auto=validate

@JacobTheLiar: tak, to jest fajne, bo Hibernate sprawdza czy się nic nie wywali przy działaniu apki. Ale spring.jpa.hibernate.ddl-auto=update wszędzie piszą, że jest niezalecane na produkcji. Chciałem się przekonać czy może jednak ludzie tak robią ;)

[JacobTheLiar]

@mk321: wszystko zależy, ogólnie z wydajnością nie ma problemu, silnik SQL jest dużo szybszy w operacjach jak Hibrnate, który zadaje multum podzapytań by zbudować drzewo obiektów. Więc osobiście wolę zbudować view (głównie do podglądu) zoptymalizować po stronie serwera i odczytać jak trzeba by biznes był zadowolony.

Co do pracy z modyfikacją danych lepiej zbudować Konwerter inaczej Adapter po stronie aplikacji, który zmapuje mi jeden obiekt na drugi używany w bazie

[k.....e]

@mk321: co to flybase?
Chyba flyway?

[JacobTheLiar]

@mk321: ogólnie jestem przyzwyczajony na przenoszenie pracy na serwer sql. To może być przyzwyczajenie/naleciałość z pracy przy budowaniu aplikacji stricte client-server, gdzie się teraz odchodzi od takiego modelu.

[mk321]

Co do pracy z modyfikacją danych lepiej zbudować Konwerter inaczej Adapter po stronie aplikacji, który zmapuje mi jeden obiekt na drugi używany w bazie danych działający już na tabelach.

@JacobTheLiar: a jasne. Czyli w kodzie masz dwie warstwy. Entity, które jest bezpośrednim odzwierciedleniem bazy danych. Tego nie zmieniasz, chyba że zmieni się baza. I druga warstwa obiektów, na których rzeczywiście operujesz, wykonujesz logikę biznesową, zmieniasz je na własne potrzeby do

[mk321]

@JacobTheLiar: tak, kiedyś było podejście: najpierw baza, potem kod.
Teraz jest częściej podejście najpierw kod, potem baza.

Jakieś procedury składowane na bazie, ręczne pisanie zapytań itd. Teraz robi się częściej z kodu i baza jest taka jak ją Hibernate wygeneruje.

[mk321]

co to flybase?

Chyba flyway?

@klepie-biede: moja pomyłka. Chodziło o Flyway.

Przez to wyniki w ankiecie mogą być trochę zakłamane :/

[JacobTheLiar]

a jasne. Czyli w kodzie masz dwie warstwy. Entity, które jest bezpośrednim odzwierciedleniem bazy danych. Tego nie zmieniasz, chyba że zmieni się baza. I druga warstwa obiektów, na których rzeczywiście operujesz, wykonujesz logikę biznesową, zmieniasz je na własne potrzeby do funkcjonalności.

@mk321: dokładnie tak.

A co jak musisz wykonać jakieś bardziej skomplikowane rzeczy na bazie? Jakieś wyszukiwarki, joiny, update batchowe, kontrola transakcji itd. Na tych pośrednich klasach ciężko to robić i tłumaczyć.

[Kresse]

@mk321: Flyway/Liquibase. Hibernate to moze co najwyzej baze pod testy postawic.