And we should try and list the top 5 use cases we trying to achieve here, that will help tailor the API and semantic and not provide something almost useful ;)
On 21 juin 2011, at 17:57, Linda DeMichiel wrote:
> Hi Adam,
>
> Thanks for raising this issue and your initial proposal. Now that the
> group has iterated over it, I think it would be very helpful if you
> could put together a revised one in terms of what functionality / APIs
> you would like to see added in view of the discussion. I think having
> something very concrete to discuss will help us converge.
>
> thanks,
>
> Linda
>
>
> On 6/21/2011 4:56 AM, Adam Bien wrote:
>> 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
>>>>
>>>>
>>>>
>>
>>