[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (HHH-7206) NaturalIdLoadAccess: NaturalId synchronization with no need to flush at all

[ https://hibernate.onjira.com/browse/HHH-7206?page=com.atlassian.jira.plug... ] Guenther Demetz edited comment on HHH-7206 at 4/2/12 4:49 AM: -------------------------------------------------------------- ??I still like the idea of "synchronization" there being the process of writing those discovered changes to the database?? @Steve: I think writing discovered changes to the database is not practicable with partial synchronizings (= synchronizing just the entity objects of the persister concerning the currently executed NaturalId lookup). Immagine having entity class A with a ToOne relation towards class B. If you associate a new persisted B instance to an A instance and then just flush the changes on persister A, this will lead to a foreign key contraint violation exception on most databases. Furthermore I like to pinpoint once again the serious implications due implicite/unnecessary flushes when implementing Long Conversations: both official solicited patterns "Detached Objects (Session per Request with DetachedObjects)" as well as "Extended Session (Session per Conversation)" do rely on the priciple having session FlushMode set to NEVER or COMMIT and thus having no implicite flush until the very last transaction. Apropos of nothing: currently with session FlushMode set to NEVER or COMMIT the NaturalIdLoadAccess don't recognizes transactional changes at all, so within Long Conversations the new feature is pretty useless: - NaturalIdLoadAccess does not consider updates: this affects the functionality of mutable NaturalIds - NaturalIdLoadAccess does consider neither inserts nor deletions: this even affects the functionality of *immutable* NaturalIds The main aspect of this improvement should be to make NaturalIdLoadAccess feasible also with implementing long conversations. was (Author: pb00067): ??I still like the idea of "synchronization" there being the process of writing those discovered changes to the database?? @Steve: I think writing discovered changes to the database is not practicable with partial synchronizing (= synchronizing just the entity objects of a singular persister): immagine having entity class A with a ToOne relation towards class B. If you associate a new persisted B instance to an A instance and then just flush the changes on persister A, this will lead to a foreign key contraint violation exception on most databases. Furthermore I like to pinpoint once again the serious implications due implicite/unnecessary flushes when working with Long Conversations: both official solicited patterns "Detached Objects (Session per Request with DetachedObjects)" as well as "Extended Session (Session per Conversation)" do rely on the priciple having session FlushMode set to NEVER or COMMIT, and thus having no implicite flush until the very last transaction. Apropos of nothing: currently with session FlushMode set to NEVER or COMMIT the NaturalIdLoadAccess don't recognizes transactional changes at all, so within Long Conversations the new feature is pretty useless: -NaturalIdLoadAccess does not consider updates: this affects the functionality of mutable NaturalIds -NaturalIdLoadAccess does consider neither inserts nor deletions: this even affects the functionality of *immutable* NaturalIds The main aspect of this improvement should be to make NaturalIdLoadAccess feasible also with implementing long conversations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira