Pobieram obiekt w @transactional. Obiekt ma pole w relecji @OneToMany(mappedBy = "xxx", cascade = CascadeType.ALL), czy transakcja na nim zadziała tzn. czy jeśli chce zmodyfikować ten pobrany obiekt wystarczy że zrobię to za pomocą settera?
Ten obiekt będzie w statusie managed?
https://i.stack.imgur.com/qMzDt.png
0
2
To zależy ;) Jeśli akurat to AOP złapie* i faktycznie odpali sie Transactional to tak, obiekt będzie managed i jego zmiana zostanie automatycznie zapisana. Osobiście uważam za tragiczny pomysł robienie czegoś takiego, niemniej powinno zadziałać.
* - jest wiele sytuacji kiedy nie złapie, np. jeśli dasz to na obiekcie który nie jest zarządzany przez kontener, albo na prywatnej metodzie, albo dasz adnotacje na interfejsie i się nie odziedziczy...
Swoją drogą powodzenia życzę potem w dochodzeniu kto, gdzie, jak i dlaczego zmienił dane w bazie ;) Ja jedak wole mieć repozytorium i wiedzieć dokładnie kiedy ktoś czyta i pisze do bazy.
0
Nie raz w tutejszych rozmowach zajmowałem nieco przychylniejsze JEE stanowisko niż inni koledzy (za to nie jestem zaangażowanym springowcem) ...
... wracając do tematu, z wielu technik które są dla mnie fajne (aktualne CDI), akceptowalne, "może być z dobrodziejstwem inwentarza", "kiepskie ale czasem trzeba" etc, pierwsze miejsce na mojej czarnej liście zajmuje adnotacja @Transactional i deklaratywne transakcje
Profesjonalne analizy są liczne (proxy, wywołanie wewnętrzne etc), więc nie będę powtarzał
Z ciekawostek, mam stary mini projekt z deklaratywnymi transakcjami i dirty checking, który chodzi na Eclipselinku a nie chodzi na Hibernate. Zgodnie z zasadą starych Indian, g... już nie ruszam...
Spełnia ważną rolę 10min / 1user / dobę i klient za zrobienie od podstaw nie zapłaci.
1
Zakładając, że masz domyślny config i nic nie grzebałeś, to tak. Relacja nie ma tutaj nic do rzeczy, ważne, że masz @Entity.
Najlepiej napisz sobie test i sprawdź, czy działa. (Żeby test był miarodajny, musisz testować na warstwie ponad @transactional żeby encja nie szła z cache (sesji).)