Pinaki/Gordon/all,
Thanks for the input. The idea of a single method like getEntities(LifeCycleState) sounds appealing. And offers flexibility by adding new states later without having to add a new method for future occasions. They all have precisely the same signature, so one combined method seems appropriate.
Werner
----- Original Message -----
From: Gordon Yorke
To: jsr338-experts_at_jpa-spec.java.net
Sent: Tuesday, June 21, 2011 12:37 AM
Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
Access to managed entities for any active persistence context is an useful feature at any point of time.
Why would you like to restrict only at flush() via callback?
By providing the information at flush() time it is easy to define what is returned without a plethora of API to distinguish the unsynchronized changes from the synchronized changes in the transaction. There's little value in combining both sets of changes into a single set.
Also retrieving the list of "dirty" entities could be quite "expensive" in some providers or deployment environments but the work to calculate the changes will already have been completed during the flush() operation.
Based on your example if you are expecting that only the unsynchronized changes are available through these sets then these APIs along with the EntityManager event would be fine, although I would suggest changing the names to reflect the EntityManager operations (ie. LifeCycleState.REMOVED).
--Gordon
Pinaki Poddar wrote:
Hi Gordon/Adam and all,
I should have clarified
a) the returned Sets be immutable. The elements of the set are live.
b) returned set reflects the state of the member entities at the time of invocation.
Set<Object> deleted = em.getEntities(LifeCycleState.DELETED); // say return a set with 2 entities
em.remove(another); // another is not a member of deleted set
assertFalse(deleted.contains(another));
Set<Object> deleted2 = em.getEntities(LifeCycleState.DELETED);
assertTrue(deleted.contains(another));
c) Other possibility is to return an Iterator<> instead which is always 'live'.
d) the methods return empty set if EntityManager is not in an active transaction.
Access to managed entities for any active persistence context is an useful feature at any point of time.
Why would you like to restrict only at flush() via callback?
Regards --
Pinaki
From: Gordon Yorke <gordon.yorke_at_oracle.com>
To: jsr338-experts_at_jpa-spec.java.net
Date: 06/20/11 11:13 AM
Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
----------------------------------------------------------------------------
Hello Adam,
Would the "dirty" set include unsynchronized persisted and removed
Entities? It would likely be better to have separate sets for these.
Without configuration these sets would have to be cleared as the
EntityManager is cleared. What effect do you see EntityManager.clear()
having on these sets?
As an alternative to the sets an EntityManager lifecycle listener
could be notified of the sets on EntityManager.flush() and the
application could track the same sets as need across flushes.
--Gordon
Adam Bien wrote:
> HI All,
>
> I would like to propose additional EntityManager methods:
>
> Set<Class> updated = EntityManager#getUpdatedEntities(Class<T>.class);
> Set<Class> deleted = EntityManager#getDeletedEntities(Class<T>.class);
> Set<Class> created = EntityManager#getCreatedEntities(Class<T>.class);
> Set<Class> dirty = EntityManager#getDirty(Class<T>.class);
>
> We had to use provider-specific EntityManager extensions to access the dirty entities for the implementation of replication or historization.
>
> Such methods would be also useful for debugging purposes,
>
> thanks in advance,
>
> adam
>
>
>