Reputation: 4564
Could you give me some practical examples that use FlushMode.ALWAYS in Hibernate session?
Thanks,
Upvotes: 1
Views: 1422
Reputation: 4876
Tests
With @Transactional
the default/implied behaviour for tests is @Rollback(true)
... With Hibernate this means that the underlying database does not get involved at all. And whatever constraints you have defined on your tables they will not be evaluated either. Should your tests violate some of those constraints you will not know about it, the tests will be passing happily. Until you override @Rollback
to false
, or enforce the flush via flush()
or FlushMode.ALWAYS
.
Upvotes: 0
Reputation: 1143
I have encountered cases where it was required. One case is below: Table A has a unique constraint on column B. You want to delete r1 and insert r2 in a single transaction, where r1.B == r2.B. Hibernate reordering within the single transaction caused a UniqueConstraintViolation. FlushMode.ALWAYS helps out here or you could do an explicit session.flush().
Upvotes: 2
Reputation: 691645
It's almost always unnecessary. It could be useful if the modifications made in the session cause some modifications when flushed in database, and these modifications can't be detected by Hibernate. For example, if some insert to table A causes a trigger to execute, if this trigger inserts rows to table B, and if you execute a query on table B. In this case, Hibernate can't detect that flushing the session is needed before the HQL query is executed.
Upvotes: 3