Regardless of what the JPA stuff is,
Jay's example is not good because he's mixing JAXB and JPA in the same object.
Service Layer is supposed to shield the clients from how the data is managed by
the application.
Regarding the JPA part, the first bulletpoint you have there is pretty much what
"attaching a detached entity" means.
________________________________
From: Moises Lejter <moilejter_at_gmail.com>
To: Ronak Patel <ronak2121_at_yahoo.com>
Cc: users_at_jersey.dev.java.net
Sent: Sun, September 26, 2010 11:08:26 PM
Subject: Re: [Jersey] Setting Id Field on JPA Entities
Hmm - but the JPA 2.0 spec, section 3.2.7.1, states:
The semantics of the merge operation applied to an entity X are as follows:
• If X is a detached entity, the state of X is copied onto a pre-existing
managed entity instance X' of the same identity or a new managed copy X' of X is
created.
• If X is a new entity instance, a new managed entity instance X' is created and
the state of X is copied into the new managed entity instance X'.
[and there are a few more cases]
I thought Jay's example would fall under the second case in that section...
And, in particular, notice how merge is *not* for attaching a detached entity
into the JPA persistence context. Re-attaching a detached entity is not an
action supported by the JPA 2.0 entity manager, AFAIK - though I believe it is
supported in Hibernate ...)
Moises
On Sep 27, 2010, at 12:39 AM, Ronak Patel wrote:
Hi,
>
>
>As long as the JPA Entity does not have an @Id that is @GeneratedValue you can
>set it.
>
>
>Remember merge is for attaching a detached entity into the JPA persistence
>context.
>
>
>If all you want to do is update a record, then what you really want to do is
>fetch the corresponding JPA managed object and set its setter methods.
>
>
>You SHOULD NOT merge an object into the persistence context to update an
>existing record.
>
>
>Ronak
>
>
>
________________________________
From: Moises Lejter <moilejter_at_gmail.com>
>To: Ronak Patel <ronak2121_at_yahoo.com>
>Cc: users_at_jersey.dev.java.net
>Sent: Sun, September 26, 2010 8:44:01 PM
>Subject: Re: [Jersey] Setting Id Field on JPA Entities
>
>Hi!
>
>
>I can see why one would want to prevent setting the @Id field of a persistent
>JPA entity - but why would it prevent the setting of that field for a transient
>one?
>
>
>As in Jay's example, I thought the whole purpose of the merge() method in the
>entity manager was to update a persistent instance from a non-persistent copy
>already obtained. If one cannot set the @Id field of the entity, then this use
>case for merge() may not make sense - so what other use cases would merge() be
>good for?
>
>
>It was my impression that the Hibernate folks would argue that the object sent
>over the wire and the one sent to the db could be the same one - thus detached
>objects, the ability to de/serialize entities, and the EM merge() method - and
>it was my impression that the JPA spec bought into this view, at least as an
>alternative - which is why these features of Hibernate are also in JPA ...
>
>
>Moises
>
>
>On Sep 26, 2010, at 10:23 PM, Ronak Patel wrote:
>
>Jay,
>>
>>
>>You cannot set an @Id of a JPA Entity that is a @GeneratedValue.
>>
>>
>>What the bookmarks example does is actually the right way of doing things.
>>Please be aware that the Entity being marshalled by JAX-RS is a JAXB Bean.
>>Architecturally, what you send over the wire and how you store the data in your
>>database are two different things (and hence separated into a Service and Data
>>Layer).
>>
>>
>>Please follow the bookmarks example.
>>
>>
>>Let me know if you have any other questions.
>>
>>
>>Ronak
>>
>>
>>
________________________________
From: Jay Bloodworth <johnabloodworth3_at_gmail.com>
>>To: users_at_jersey.dev.java.net
>>Sent: Sun, September 26, 2010 5:47:54 AM
>>Subject: [Jersey] Setting Id Field on JPA Entities
>>
>>This is arguably more a JPA question than a Jersey question, but I'm
>>doing the stuff in a RESTful context and the way Jersey marshals objects
>>may be relevant, so here I am.
>>
>>I want to do something like:
>>
>>@PUT
>>@Consumes("application/json")
>>@Produces("text/html")
>>public String doUpdate(Entity entity) {
>> em.merge(entity);
>> return "Success";
>>}
>>
>>And then update the datastore by PUTing something like {"id" : 5, "name"
>>: "New Name", etc}.
>>
>>(This is actually only my test case; the real handler will return a
>>Response and will use a Path Param to set the id. But the issue is the
>>same either way.)
>>
>>The problem is that JPA (I'm using Eclipselink) blocks explicit setting
>>of the @Id field, so it ends up being null in the entity passed to the
>>handler. I've looked at the bookmarks example and it sidesteps this
>>issue by using a proxy object to receive the updated fields, then copies
>>them into a managed copy of the entity from the datastore. That's easy
>>enough to do, but it seems to undermine some of the elegance and even
>>purpose of the ORM if you have to copy the fields around yourself.
>>
>>Any suggestions?
>>
>>Thanks,
>>Jay
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>>
>
>
>