Relacja wiele do wiele - JPA

0

Cześć!
Natknąłem się na kolejny tym razem podczas tworzenia relacji. Użytkownik może składać wiele ofert a wiele ofert może mieć wiele użytkowników. W dodatkowej tabeli która łączy relację chciałbym umieścić pole wiadomosć. Niby wszystko jest dobrze, ale tworzą się dodatkowe wiersze o nowym ID dla użytkownika i oferty.

Edit: Dodatkowo wspomnę, że najpierw przez kontroler tworzę użytkownika i ofertę, a dopiero poźniej chcę sobie to dodać.

1.PNG

2.PNG

3.PNG

2

IMG-7764

  1. Nie wklejaj screenów kodu
  2. Pokaż kod kontrolera
  3. Co to znaczy "tworzą się dodatkowe wiersze o nowym ID dla użytkownika i oferty"
1

Załóżmy tak jak napisałeś, że najpierw z kontrolera tworzysz Usera i Ofertę, powiedzmy o ID = 1 każde. Później dodajesz Application, które ma ustawione tego Usera o ID = 1 i Ofertę o ID = 1 i mimo to tworzy się nowy User i Oferta? Coś nie pasuje, na pewno ustawiasz podczas tworzenia Application poprawnego Usera i Ofertę?
Jeśli nie wyciągasz Usera i Oferty z bazy, to musisz mieć odpowiednie proxy hibernateowe (utworzyć z poprawnym ustawieniem ID obiekty poszczegolnych klas). Jeśli ustawiasz nowego Usera i Ofertę, które mają ID = null, to wtedy naturalnie stworzą się nowe rekordy, kaskadujesz persystowanie ich.

0

@Charles_Ray:

  1. Ok rozumiem.
  2. W kontrolerze przekazuję id użytkownika i oferty , żeby znaleźć je i pobrać.
  3. Wstawia mi d taki sam wiersz jak przed utworzeniem(tylko jest nowe id) Uzytkownika dla użytkownika i to samo dzieje się w Ofercie
3

Masz detached encje, przeklejam mój komentarz cytując sam siebie niczym nie wiem kto ;)

No to nie zadziała - dla JPA to są nieznane obiekty, które zostaną dodane do bazy. Aby to zadziałało musisz je najpierw pobrać przez JPA, ustawić w tej Application, a dopiero potem zapisać. Podobna „chryja” jest z usuwaniem.

Pytanie za 100 punktów - po co masz ustawione kaskady w encji Application?

0

@Charles_Ray:

Pytanie za 100 punktów - po co masz ustawione kaskady w encji Application?

Bez tego mam: save the transient instance before flushing

2

Ano właśnie ;) rozwiązujesz niewłaściwy problem (komplikujesz rozwiązanie, które dalej nie działa). Wywal te kaskady i zrób tak jak napisałem - powinno pomóc ;)

Przeczytaj proszę: https://www.baeldung.com/hibernate-entity-lifecycle

Jeśli chcesz zrozumieć JPA, to: https://github.com/fdescamps/ocejpa/blob/master/projpa2/Pro%20JPA%202%2C%202nd%20Edition.pdf (z tego się uczyłem X lat temu do certa, niewiele już pamiętam).

4

Ja polecę jeszcze tego pana:

https://vladmihalcea.com/the-best-way-to-map-a-onetomany-association-with-jpa-and-hibernate/

Ogólnie nie ma co w ogóle używać @OneToMany, po drugiej stronie trzymać po prostu id parenta, a jak chce się daną kolekcję, to Spring Data repository.findByParentId(Long parentId)

1 użytkowników online, w tym zalogowanych: 0, gości: 1