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