Adam, Pinaki -- thanks! It looks like we are getting close.
Since there has been a lot of back-and-forth on this, could one or
the other of you please summarize what you think is the current state
of the proposal for us in one place, including please
- final version of the enum
- semantics of enum values (e.g., does dirtiness include state of
element collections, etc.)
- flushed vs unflushed distinctions if any
- semantics of returned set
- when this method is callable (if not unrestricted)
- ...
thanks again,
-Linda
On 6/23/2011 1:33 AM, Adam Bien wrote:
> Hi Linda,
>
> I like Pinaki's proposal now better than my - lets go with his suggestion (I'm not sure about the includeSubclasses):
>
> <T> Set<T> getEntities(Class<T> entityType, boolean includeSubclasses, LifeCycleState... states);
>
> If hard to implement - we could return "dehydrated" Entites as suggested by Emanual.
>
> Top 5 Use Cases:
>
> 1. Implementation of cache synchronization
> 2. Transparent synchronization between RIA apps and serverside EMs
> 3. Auditing
> 4. Versioning / Historization
> 5. Delta Computation for efficient object transfer (similar to 2)
> 6. Debugging / Unit Testing purposes
>
> thanks!,
>
> adam
> On 21.06.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
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>