Witam
Zwracam się z następującą zapytaniem: jak mogę przy użyciu hibernate automatycznie utworzyć tabele za pierwszym uruchomieniem(tzn chce przy teście utworzyć tabele,a potem już korzystać z istniejących). Mam 2 klasy POJO gdzie zastosowałem adnotacja(javax.persistence) i hibernate.cfg.xml
Proszę o odpowiedź
0
0
w pliku persistence.xml ustawiasz wartość:
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
wtedy przy deployu aplikacji hibernate usuwa (jeśli istnieją) i tworzy tabele
a jak już utworzysz to najlepiej zmień na "validate", żeby hibernate sprawdzał strukturę czy jest zgodna
0
Tutaj masz przykład http://candidjava.com/hbm2ddl-auto-hbm2ddl-auto-update-example-program-in-eclipse
w pliku Hibernate.cfg.xml zmieniasz <property name="hbm2ddl.auto">update</property> dajesz albo update albo create
0
Właśnie próbowałem i coś mi nie działa
HHH000038: Composite-id class does not override equals()
HHH000039: Composite-id class does not override hashCode()
Takie mam worny jak odpalam junit
0
Na testach tak, ale nie na produkcji. Na produkcji stosujemy validate i wersjonowanie bazy za pomoca np. dbup. Na testach/dev dajesz update. Jak dasz create-drop to za każdym uruchomieniem hibernate usunie istniejące tabele i stworzy je od nowa. Usuwając przy okazji dane. Jak dasz create, to pierwsze uruchomienie wygeneruje tabele, ale każde kolejne zakończy się błędem.
Jeszcze warto zapoznać się z konfiguracją loggera i flagą log4j.logger.org.hibernate.tool.hbm2ddl=trace. Raz wygenerować sobie DDLa i zapomnieć.
Co do warnów - należy nadpisać metody hashCode i equals, ale nie generować ich na pałę za pomocą IDE. Przeczytaj > http://stackoverflow.com/questions/5031614/the-jpa-hashcode-equals-dilemma
I tu uwaga, bo dużo zależy od tego jak będziesz chciał tworzyć klucz główny encji. Osobiście preferuję klucze naturalne, bo są bardzo intuicyjne i wymuszają w wielu przypadkach prawidłowy stan obiektu (sami decydujemy co tworzymy i musimy zrobić to dobrze - nie zapomnimy o czymś w kodzie). Niektórzy lubią klucze sztuczne (surrogate keys). Te stosuję tam gdzie ciężko określić jakiś jeden klucz główny we w miarę prosty sposób.
Samo pisanie z palca hashCode i equals też nie do końca ma sens. Warto użyć klasy Objects > https://docs.oracle.com/javase/8/docs/api/java/util/Objects.html i znajdujących się tam metod.
0
Ja z tymi hashCode() i equals() poradziłem sobie tak że właśnie zamieniłem int na Integer i zadziałało,nic nie musiałem nadpisywać ;)
A teraz takie pytanie by nie zaczynać znowu wątku:
Jeżeli mam relacje wiele do jednego i załóżmy nie zmieniam samych zwykłych pól rodzica a w trakcie korzystania z aplikacji dodaje nowe dzieci do zbioru,to jak powinienem to zapisać? Użyć session.save() czy session.update() ?
0
@scibi92 to zależy od tego jak ustawiłeś "mapped by" i czy relacja jest obustronna. Jeśli jest obustronna to jedna strona relacji jest "właścicielem". Jeśli właścicielem jest strona "jeden" to wystarczy że dodasz elementy do seta i zrobisz update. Jeśli jednak właścicielem jest strona "wiele" to ustawiasz odpowiednią referencje w tym obiekcie a potem robisz na nim save (bo jest nowym obiektem, jeszcze nie zapisanym w bazie).
0
Jest to relacja wiele do jednego i mam w jednym przypadku:
@OneToMany(mappedBy="owner",cascade={CascadeType.ALL,CascadeType.PERSIST,CascadeType.MERGE} )
-Właściciel
@ManyToOne(fetch=FetchType.EAGER,cascade=CascadeType.ALL)
@JoinColumn(name="userId")
- Dziecko
Owner jest w klasie "dziecko" i w momencie gdy dodaje dziecko to set mam setOwner(this) (wywowałene z klasy właściciela)
Tak jak tutaj: http://stackoverflow.com/questions/8931342/what-does-relationship-owner-means-in-bidirectional-relationship w 1 przypadku
Czyli jak tylko dodaje dziecko to mam na nim po ustawieniu ownera zrobić save?
0
Tak. I absolutnie nie dodawaj czasem tego dziecka do kolekcji w klasie rodzica samemu bo ci się będą dublować rekordy. Modyfikacje robisz tylko po stronie właściciela.