Ahoj,
lepsi nez em.flush() je chytat vyjimku po skonceni transakce. Bude to
RollbackException. Napr.:
try {
em.getTransaction().begin();
Programmer p = em.find(Programmer.class, 1L);
em.remove(p);
em.getTransaction().commit();
} catch (RollbackException e) {
...
}
I v takovem pripade se ovsem v logu objevi chyba od databaze. Je to
logicke: poslali jsme ji prikaz, ktery skoncil chybou a to by se melo vzdy
logovat. Ze to na urovni aplikace neni chyba, databaze nevi.
Resit to jde na aplikacni urovni: umoznit uzivateli mazani jen tech entit,
na ktere nejsou odkazy. Tj. napr. pokud uzivatel vybira entity ke smazani
z nejakeho seznamu, tak v seznamu zobrazit jen entity, na ktere nesmeruje
zadny odkaz.
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Ondra Medek napsal(a):
> Ahoj,
>
> chci vymazat JPA entitu, ktera muze byt refencovana pres cizi klice. V
> takovem pripade chci uzivateli zobrazit nejake hlaseni "nelze
> vymazat". Klasicke JDBC reseni bych delal pres DELETE FROM ...,
> odchytnu SQLException a zobrazim hlaseni. V JPA/Hibernate mohu delat
> neco podobneho:
>
> try {
> em.remove(...);
> em.flush();
> } catch () {
> // nelze vymazat
> }
>
> Tady mne zarazi, ze:
>
> 1. catch chyti jakousi obecnou javax.persistence.PersistenceException
> (nested org.hibernate.exception.GenericJDBCException a dalsi nested
> java.sql.BatchUpdateException: failed batch)
> 2. Hibernate zaloguje chyby:
> 14:43:09,890 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: null
> 14:43:09,890 ERROR [JDBCExceptionReporter] failed batch
> 14:43:09,890 ERROR [AbstractFlushingEventListener] Could not
> synchronize database state with session
>
> Tak si rikam, ze to asi nebude spravne reseni, kdyz Hibernate loguje
> chyby. Navic nechci mit v logu chyby, kdyz vlastne k zadne chybe
> nedoslo. Nemohu ovsem najit, jak se ma v takovem pripade spravne
> postupovat? Manualni kontrola JPQL/HQL query pred em.remove()? Pokud
> ano, neni to trochu tezkopadne?
>
> Dik za radu
> Ondra Medek
>
