users@jersey.java.net

Re: [Jersey] Setting Id Field on JPA Entities

From: Moises Lejter <moilejter_at_gmail.com>
Date: Sun, 26 Sep 2010 22:44:01 -0500

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