[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2439?page=c...
]
Steve Ebersole commented on HHH-2439:
-------------------------------------
Certainly it is a subtle change that has potential to break existing applications.
But are those existing applications relying on questionable behavior? I'd argue yes.
Would you agree that what we do now is correct for out-of-transaction operation? So why
not extended to FlushMode.MANUAL?
As for the app relying on the id value being available, then those apps are clearly not
relying on a spec defined behavior. I'd argue that they were relying on a quirk in
our implementation. As you outline so well in the book, according to JPA spec, they
should not rely on a generated id being available in memory until the next flush cycle
which incorporates the entity.
delay IDENTITY insertions in the case of FlushMode.MANUAL/NEVER
---------------------------------------------------------------
Key: HHH-2439
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2439
Project: Hibernate3
Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Fix For: 3.2.3
Much like we do now in 3.2 for out of transaction operations, we should delay performing
insertions for post-insert generators with FlushMode.isManualFlushMode
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira