Hibernate - automatyczne tworzenie tabel przy pierwszym uruchomieniu

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ź

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

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

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

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.

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() ?

@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).

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?

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.