On 22.06.2011, at 16:34, Emmanuel Bernard wrote:
>
> On 20 juin 2011, at 20:33, 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));
>
> I wonder if the Sets should return some dehydrated forms of the Entities instead of the entities themselves?
It could be a Map-like change set. If possible I would go with JPA-entities because of usability issues.
>
>>
>> c) Other possibility is to return an Iterator<> instead which is always 'live'.
>>
>
> I'd prefer the set to be cast in stone at method execution time.
>
>> d) the methods return empty set if EntityManager is not in an active transaction.
>>
>
> Well, an extended PC does have a queue of managed objects. I'd say it's useful to have access to them. That'd require some kind of a "fake flush" to compute the closure I suspect.
>