Hi,
To complement the current proposal on access to the managed entities
filtered by their life cycle states (and flush state - which as per
earlier comment of Michael Bouscher is not strictly a life cycle state,
and I agree), we could consider a Transaction listener plug-in point for
the application.
Current listeners are tied to entity life cycle, not transaction. In
combination, many use cases that are mentioned by Adam Bien and others
could be addressed, I believe.
Regards --
Pinaki Poddar
Apache OpenJPA Project Chair
http://openjpa.apache.org/
JPA Expert Group Member
Application & Integration Middleware
From: Adam Bien <abien_at_adam-bien.com>
To: Linda DeMichiel <linda.demichiel_at_oracle.com>
Cc: jsr338-experts_at_jpa-spec.java.net
Date: 06/23/11 01:35 AM
Subject: [jsr338-experts] Re: Standardized Access to ChangeSet
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