Hi Linda, Pinaki, Adam, all,
thank you very much for providing this proposal. Please find some
comments inline.
Linda DeMichiel, am 7 Jul 2011 hast Du um 12:50 zum Thema "[jsr338-experts] ChangeSet proposal [was Re: Re:" geschrieben :
> Their latest proposal draft follows below. Please post feedback to
> the group.
[...]
> Life Cycle States of a managed Entity
> --------------------------------------
>
> The life cycle states of an entity is enumerated in javax.persistence.LifeCycleState.
Actually, we either have to better align the life cycle states listed
below with section 3.2 or find another term for it than life cycle
state, I think. In particular state new is a bit confusing as it
definitely does not mean new as per 3.2. Rather, new, clean, dirty and
hollow detail out managed to my understanding.
> package javax.persistence;
> public enum LifeCycleState {
> NEW, // newly persisted in the current transaction
> CLEAN, // present in the current transaction but not modified
> DIRTY, // present in the current transaction and modified
> HOLLOW, // referred in the current transaction (see getReference()),
> // but its persistent state may or may not be populated
> REMOVED // marked for deletion
> }
>
> Definition of each life cycle state
> -----------------------------------
> NEW represents the state of an entity which has been instantiated via new operator of Java language
> and added to the persistence context either directly via persist() method or is indirectly reachable
> via cascaded relation to another instance which has been merged via merge() method.
or persisted.
> CLEAN represents the state of an entity which has been retrieved from the database via query of find()
> and has not been modified.
>
> DIRTY represents the state of an entity which has been retrieved from the database and subsequently
> modified. Modification implies that either any of it non-relational property value has been changed
> or any of relation has changed to a new reference. Modification does not imply change in content of
> a many-valued relation. For example, if a parent object P has a many-valued relation to a collection
> C of child objects, then adding a new child object in the collection C does not dirty the parent P.
> But replacing the collection C itself by another collection does.
I'd rather see a definition here based on the owning side of a
relationship that goes in line with the update of the version field as
per 3.4.2.
Assuming bytecode weaving has been switched off or is not present, do
you expect the provider to perform a before-image comparison everytime
an entity set is requested where state dirty is involved ?
> HOLLOW represents the state of an entity which can be referred in the persistence context but
> its persistent state is not populated. This state occurs when an entity is obtained via getReference()
> method that was not present in the current context.
>
> REMOVED represents the state of an entity which has been removed either via direct remove() operation
> or indirectly via cascaded relation to another instance which has been removed.
>
> It is important to note that the states are not strictly mutually exclusive. An instance could be
> newly persisted (i.e. NEW state) as well as marked for removal (i.e. REMOVED stated) in the same context.
> However, DIRTY and REMOVED are mutually exclusive.
To see whether this proposal really is applicable, we would probably
have to work out a detailed state transition diagramm with all relevant
events and check it for its plausability very carefully. And if we
really were to allow for states not being mutually exclusive we would
have to spec out the possible combinations in detail. At least to me,
they don't pop up immediately by nature.
Actually, I have to admit that I am a bit sceptical whether we may
achieve a common view over all implementations.
E.g. when exactly turns hollow into clean (apart from the obvious
refresh) ? What about a sequence like find -> modification -> flush ->
detach -> find -> commit ?
> Access by Life Cycle State
> --------------------------
> The managed instances are queried by their life cycle states via EntityManager interface.
> The resultant set contains the entities currently managed by the persistence context
> and satisfying the given conditions on their life cycle state and state of synchronization
> to the database. Because the state of a member entity can change later in way that the basic
> condition of its membership may not be valid anymore. For example, a CLEAN entity may be
> modified to change in DIRTY state. Hence the resultant set reflects the persistence context
> at the time of invocation.
Well, I am wondering if methods like isDirty(Object entity),
isClean(Object entity) on the entity manager might sometimes be more
helpful than computing a large change set.
> The access API also uses a tertiary condition to designate the state of synchronization of
> an entity with the database i.e. whether an entity has been flushed or not to the database.
> Flush operation does not change the life cycle state.
It feels a bit strange to me that dirty doesn't turn into clean upon
flush. Also, what happens in an extended persistence context upon
commit?
[...]
> * @param includeFlushed flags if the resultant set based on life cycle states is further filtered
> * by flushed state of the entities.
> * <tt>true</tt> implies the resultant set will include entities whose state
> * are currently synchronized to the database by flushing
> * <tt>false</tt> implies the resultant set will include entities whose state
> * are not currently synchronized to the database by flushing
> * null implies the resultant set will include both synchronized and
> * unsynchronized entities
Well, I'd rather call it something like 'flushed'. For 'includeFlushed'
being true seems to suggest to me that synchronized entities are
included to what is returned when the paramater has been set to false.
However, this is not the case; you rather have to provide null for that
purpose.
[...]
Thanks again for having worked out this proposal.
Best regards
Rainer
---
Rainer Schweigkoffer SAP AG Walldorf
Business Solution & Technology TD Core JS&I
Technology Development Dietmar-Hopp-Allee 16
Java Server Core D-69190 Walldorf
JEE Implementation Group phone: +49 6227 7 45305
Building 3, I.3.14 fax: +49 6227 7 821177
rainer.schweigkoffer_at_sap.com
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Werner Brandt, Angelika Dammann,
Bill McDermott (Co-CEO), Gerhard Oswald, Vishal Sikka,
Jim Hagemann Snabe (Co-CEO)
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying, or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your
cooperation.