Cześć
Zastanawiam się czy w EntityManager merge jest możliwość podmiany całego obiektu zamiast pracochłonnego ustawiania każdego atrybutu osobno?
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
0
Nie rozumiem pytania. Jak dasz temu swojemu "całemu" obiektowi ID i zrobisz merge to stanie się to o co pytasz...
- Rejestracja:ponad 9 lat
- Ostatnio:ponad 7 lat
- Postów:53
0
@Transactional
public void editBook(Book book) {
entityManager.merge(book);
}
Mam coś takiego i zero reakcji, czy błedu czy coś. Jak mam rozumieć nadanie mojemu obiektowi ID? Book który jest przekazywany do metody posiada komplet pól łącznie z ID, możesz rozwinąć?
edytowany 1x, ostatnio: efem
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
1
I ja myśle że zostaje. merge() zwraca ci obiekt zsynchronizowany z bazą. Zobacz czy ten obiekt który dostajesz ma poprawnie ustawione pola. Bo przecież rozumiesz że niekoniecznie od razu wygeneruje to zapytanie do bazy, prawda? Jak chcesz sobie to wymusić do daj flush() na entitymanagerze...
edytowany 1x, ostatnio: Shalom
- Rejestracja:prawie 13 lat
- Ostatnio:prawie 8 lat
- Postów:13
0
Mozesz jeszcze pokazac kod klasy domenowej Book.
Kolejna sprawa, jesli klasa Book ma np. takie atrybuty:
Long book_id;
String title;
String author;
a Ty zrobisz sobie obiekt ktory bedzie mial tylko ustawione book_id i title to przy mergowaniu o ile sie nie myle autor zostanie ustawiony na null.
W takiej sytuacji przydaloby sie zaciagnac obiekt z bazy na podstawie book_id, zmergowac oba obiekty pomijajac nullowe wartosci i wtedy zrobic merga na bazie.
edytowany 1x, ostatnio: raker
Zobacz pozostały 1 komentarz
@niezdecydowany ja napotkałem kiedyś taki problem, że korzystając z jsf miałem poprzez formularz ustawione tylko ninektóre parametry obiektu, pozostałe nie edytowane były nullami i też właśnie nulle leciały do bazy, tylko o to mi chodziło. Sytuacja z życia to np. zmiana hasła usera, gdzie edytujemy tylko hasło, pozostałe atrybuty są nullami.
tutaj akurat była sytuacja, że obiekt zawsze wracał z edycji kompletny (wymagalność pól), więc nulli nie było. Problem był brak jakiegokolwiek updejtu na bazie. Flush() pomogło ale w końcu poszedłem w stronę Spring Data JPA i saveAndFlush() załatwia zarazem nowe rekordy jak i update istniejących.
NIe ustawiam Nulli fizycznie tylko np. dla Stringa defaultowa wartosc to null. Oczywiscie mozna przekazac nie edytowane parametry w hiddenach, ale jak nie chce sie ich miec w formie to trzeba odpowiednio to przygotowac
1
raker napisał(a):
Mozesz jeszcze pokazac kod klasy domenowej Book.
Kolejna sprawa, jesli klasa Book ma np. takie atrybuty:
Long book_id;
String title;
String author;
>
> a Ty zrobisz sobie obiekt ktory bedzie mial tylko ustawione book_id i title to przy mergowaniu o ile sie nie myle autor zostanie ustawiony na null.
> W takiej sytuacji przydaloby sie zaciagnac obiekt z bazy na podstawie book_id, zmergowac oba obiekty pomijajac nullowe wartosci i wtedy zrobic merga na bazie.
Specyfikacja mówi krótko "The application must not change the value of the primary key [10] . The behavior is undefined if this occurs. [11]". Czyli jeśli wiemy, że mamy książkę o id=10 w bazie, to żeby zmienić jej tytuł nie robimy:
```java
Book book = new Book();
book.setId(10);
book.setTitle("asd");
em.merge(book);
tylko
Book book = em.find(Book.class, 10); //albo getReference
book.setTitle("asd");
//em.merge(book); //juz niepotrzebne, bo po wykonaniu find book i tak jest w PersistenceContext
Mergować można z tego co pamiętam encje które są w stanie detached i zserializowane.
Sytuacja z życia to np. zmiana hasła usera, gdzie edytujemy tylko hasło, pozostałe atrybuty są nullami.
Do tego powinien być zrobiony osobny formularz (drugi na tej samej stronie). Ewentualnie ten rzadko używany feature JSF o nazwie valueChangeListener, i tam powinien być edytowany atrybut encji.
niezdecydowany