It's not a problem that I need to solve at the JPA layer... I was just
providing a use case where one would want to know...
Personally, I see too much magic in the merge semantics to be comfortable
using it...
For example, what happens to the child elements referenced in the child
collections... if I have elements extra to in the DB and I'm missing
elements from the DB and I've updated elements in the DB and left some
alone....
AFAIK, either it _should_ do exactly what I want it to do, or it will fuck
it all up... so I end up writing manual merge code... and then I just write
the full merge code myself, using the POJOs as detached objects anyway
-Stephen
2008/12/8 Markus KARG <markus.karg_at_gmx.net>
> I see, you want something like the difference between HTTP's result codes
> 404 NOT FOUND and 410 GONE... I understand.
>
>
>
> Such an automated support is not possible since RDBMS do not know wheter an
> instance had been there before and was deleted, or just have never existed.
> JPA is just a layer ontop of an RDBMS, so it cannot know that the instance
> was there before and was deleted or never existed at all (unless the JPA
> implementation has permanently exclusive access to the entity's mapped
> tables, what is most seldomly the case in the real world).
>
>
>
> From the JPA view what you want seems to be covered by chapter 3.2.4.1Merging Detached Entity State: "...If X is a removed entity instance, an IllegalArgumentException
> will be thrown by the merge operation (or the transaction commit will
> fail)....". But I doubt that it will work, because of what I wrote before:
> How shall the JPA provider know whether the instance was deleted by a third
> party (non-JPA-accessor of the same table)?
>
>
>
> What you can do to workaround obviously is to distinguish between CREATE
> and UPDATE methods in your server interface (in the CRUD sense): If the user
> creates a new instance (CREATE) then do em.persist(), it will throw an
> exception if the row already exists; if the user wants to edit an existing
> (or meanwhile potentially deleted) instance (UPDATE) then do em.find()
> before em.merge(), so you will get the wanted NotFoundException. I think
> that solves exactly your needs and the interface is rather RESTful... :-)
>
>
>
> Have Fun
>
> Markus
>
>
>
> *From:* Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
> *Sent:* Montag, 8. Dezember 2008 20:02
> *To:* persistence_at_glassfish.dev.java.net
> *Subject:* Re: Determining if entity has been removed
>
>
>
> Here's one use case off the top of my head
>
> I have a detached entity... and I'm wanting to merge it back... was it
> deleted by somebody else while I was working on it (in which case I should
> throw and error back to the user about somebody else changing the record)?
>
> By default, currently, merge in such a case will add the entity back in!
>
> 2008/12/8 Markus KARG <markus.karg_at_gmx.net>
>
> AFAIK JPA does not contain a means of detection wheter an entity has been
> removed, but only whether an instance of an entity is present or not. Also
> I
> do not see a sense in such a detection. What shall it be good for?
>
>
> > -----Original Message-----
> > From: Farrukh Najmi [mailto:farrukh_at_wellfleetsoftware.com]
> > Sent: Sonntag, 7. Dezember 2008 23:14
> > To: persistence_at_glassfish.dev.java.net
> > Subject: Determining if entity has been removed
> >
> > Dear colleagues,
> >
> > How can I determine whether an entity has been removed within the
> > EntityManager?
> > More generally is there any way in the JPA API to determine status of
> > an
> > entity within
> > the EntityManager? It does not appear to be possible. If not possible,
> > is this something useful to
> > consider for future version of API?
> >
> > Thanks.
> >
> > --
> > Regards,
> > Farrukh Najmi
> >
> > Web: http://www.wellfleetsoftware.com
>
>
>