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

[Guenther Demetz (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46143#comment-46143 ] 

Guenther Demetz edited comment on HHH-7206 at 4/2/12 5:01 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 of the main aspects of this improvement should be making NaturalIdLoadAccess feasible also with implementing *long* *conversations*. 
As you surely know, 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. Thus we cannot execute anything to database during NaturalIdLoadAccess if using FlushMode < Auto


Currently with session FlushMode set to NEVER or COMMIT the NaturalIdLoadAccess don't recognizes transactional changes at all, 
so within Long Conversations the NaturalIdLoadAccess 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

  



      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 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.
  


  
> NaturalIdLoadAccess: NaturalId synchronization with no need to flush at all
> ---------------------------------------------------------------------------
>
>                 Key: HHH-7206
>                 URL: https://hibernate.onjira.com/browse/HHH-7206
>             Project: Hibernate ORM
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 4.1.1
>         Environment: Hibernate4, database-independent
>            Reporter: Guenther Demetz
>              Labels: flush, naturalId
>
> With few code changes I think it is possible to make NaturalIdLoadAccess work with no need to rely on flush at all,
> please see following comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira