HI Gordon,
On 20.06.2011, at 20:12, Gordon Yorke wrote:
> Hello Adam,
> Would the "dirty" set include unsynchronized persisted and removed Entities? It would likely be better to have separate sets for these.
Separation would be even better. In the past I just accessed TopLinks internals to get this information :-). removed and unsychronized entities are also important if you would like to implement a cache coordination (like Eclipse Link), or something like Envers.
> 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?
IMHO the results should be empty after a clear. But I'm open for any suggestions: I never implemented a JPA provider by myself entirely :-)
> 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.
EntityListener is also fine - explicit methods, however, are more straight forward to use.
--adan
>
> --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
>>
>>
>>