Hi Laird,
Your write-up and the referenced SO post were helpful in understanding the
dilemma of JPA merge and the DIY approach. Unfortunately, I couldn't make
the leap to your proposal:
> Would it make sense to add a find() variant that takes both an ID
> and a version and throws an OptimisticLockException if a persistent
> entity with those coordinates does not exist? Or am I missing
> something more fundamental somewhere in the API that would explain
> why this is not needed?
Specific to your request, how is this proposal different from just doing
the normal find() operation with the ID and then just comparing the
version that is returned with the version you are interested in? As your
previous paragraph suggested... This approach avoids the exception
processing overhead as well, which I am not in favor of. You are just
trying to move this version compare logic from the user to the JPA
provider? Hmmm... Just not seeing the advantage here.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter
Laird Nelson <ljnelson_at_gmail.com> wrote on 06/17/2014 12:30:22 PM:
> From: Laird Nelson <ljnelson_at_gmail.com>
> To: users_at_jpa-spec.java.net
> Date: 06/17/2014 12:31 PM
> Subject: [jpa-spec users] Enhancement: EntityManager.find() method
> that takes an ID and a version?
>
> Hello; many people use "DIY" merging. Here's a nice StackOverflow
> treatment of the subject: http://stackoverflow.com/questions/
> 14141156/jpa-merge-in-a-restful-web-application-with-dtos-and-
> optimistic-locking
>
> When using DIY-merging, typically you have only a couple values
> received from, e.g., the web form that represent the user's intent
> to change only part of a logical object. For example, given a
> hypothetical person entity with 27 fields in it, the user may have
> only changed the last name. In that case, in many applications, all
> you have to work with coming in over the wire is an ID, a version
> value representing the version value of the entity at edit time (if
> you're doing things right), and the new last name value. The
> salient point here is you don't have the full state of the entity,
> just a logical command that the user wants effected—"please set the
> last name of person ID=4 to 'fred' provided that the person record
> on disk is version 3".
>
> In such a case you then ask an entity manager to find the entity
> with the specified ID so you can begin the process of setting the
> last name on the persistent entity.
>
> But if you're doing things right, you have to manually compare that
> persistent entity's version with the version value you have from the
> web form to ward off concurrent changes. You, the JPA programmer,
> are responsible for doing this, not the JPA provider. That seems odd to
me.
>
> Would it make sense to add a find() variant that takes both an ID
> and a version and throws an OptimisticLockException if a persistent
> entity with those coordinates does not exist? Or am I missing
> something more fundamental somewhere in the API that would explain
> why this is not needed?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson