[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3018) Configuration element to tell Hibernate to have just one insert to flush an entity and not both an insert and an update.

[Julian Klein (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38439#action_38439 ] 

Julian Klein commented on HHH-3018:
-----------------------------------

Although we haven't yet added the configuration element support, a patched version of Hibernate Core 3.5.6-Final can be found in the below link that addresses this issue.  We found this to be a performance issue (among other problems) when using Spring Webflow and an extended persitence context (session-per-conversation).  The patched code can be found here:

http://github.com/sfraser/Hibernate-Core-3.5.6-Final-patched-with--True-Coalesce--enhancement

> Configuration element to tell Hibernate to have just one insert to flush an entity and not both an insert and an update.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HHH-3018
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3018
>             Project: Hibernate Core
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.2.5
>            Reporter: Nicolas Cazottes
>         Attachments: testXMLTypeUpdates.zip
>
>
> While analyzing the SQL queries Hibernate generates to persist objects, I fall on a behaviour, that I first found strange, which is that in one flush of one transaction, there may be both an insert and an update for a given entity. My first expectation was to have only one insert and no update.
> After a few search, I discover that conversation (http://forum.hibernate.org/viewtopic.php?p=2191664&sid=c571096bda4a6b636e0a8e69646b4638) that explains it is normal in the case of a save with modifications after save.
> I discover (cf the classes of my zip showing it) that this behaviour is also present in the case of a relation that is managed by cascade. What I noticed is that the insert of the related entity is planned when the first hql query is executed after the relation has been established. So if the related entity is modified after the query execution (for exemple depending on the result of the query), an update will be executed. 
> This behaviour is understandable but in my case, the update is really expensive (because it acts on an XMLType column) and unless I set a FlushMode to COMMIT (which I found really not a good solution), I can not control that Hibernate will generate both an insert and an update or only an insert. I know I could also set the relation just before the commit in order to avoid insert+update but this solution is not possible in my case and I find it not elegant (it would break the semantic of the cascade of the relation).
> I suggest to introduce a new configuration element (similar to the flushmode) in Hibernate in order to be able to have control whether Hibernate generates an insert containing the data of the entity at the first save or an insert containing the data of the entity at the flushing time.
> Note : The attached files (which is the smallest extraction of what does my application) shows that behaviour both for the save call and the cascade declenched by a query.
> Note2 : I found an issue in jira number 2621 submited by someone else that is related to this subject in think.

-- 
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira