openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick (JIRA)" <>
Subject [jira] [Commented] (OPENJPA-1973) Unlocked field support
Date Fri, 08 Apr 2011 16:24:05 GMT


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

View raw message