I am uncertain what you like to reach. You asked for magic, now you say you
don't like any magic. So what is the target of this discussion thread?
From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: Montag, 8. Dezember 2008 21:22
To: persistence_at_glassfish.dev.java.net
Subject: Re: Determining if entity has been removed
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.1
Merging 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