[
https://issues.apache.org/jira/browse/OPENJPA-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017518#comment-13017518
]
Michael Dick commented on OPENJPA-1973:
---------------------------------------
I have a little trouble seeing a use case. I see the unlocked fields as
metadata which isn't really part of the state of the entity. I'm not entirely
clear when you'd want to update the unlocked fields without changing any of the
other fields.
To use your examples, when would you update the lastCommitInt or
lastCommitString without also updating regularlyLockedField? Or in the
PurchaseOrder case, if a line item has been added, and PurchaseOrder owns the
relationship you''ll want a version update. If PruchaseOrder is not the owner,
we don't update it's version column IIRC.
I'm willing to accept that there are use cases that I've missed and wouldn't
stop this from going into trunk. I'm just not sure how I'd explain why you'd
use this if I was asked.
> Unlocked field support
> ----------------------
>
> Key: OPENJPA-1973
> URL: https://issues.apache.org/jira/browse/OPENJPA-1973
> Project: OpenJPA
> Issue Type: New Feature
> Components: docs, jdbc, jpa
> Reporter: Patrick Linskey
> Assignee: Patrick Linskey
> Attachments: OPENJPA-1973-with-docs.patch, OPENJPA-1973.patch
>
>
> Often, it's desirable to exclude certain fields from the optimistic locking
> computation. For example, if a PurchaseOrder's lastUpdatedDate field is
> updated every time a line item is added, it may be acceptable to simply use
> the latest value instead of requiring an optimistic lock check / collision.
> Let's add support for such fields.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
