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