Q. What I was wondering is if I have registered my second editing context as a child of the default one, create my objects in this new editing context, commit its changes, should it not pass these changes back up to its parent ? Or does that not include passing the new object back up but only changes to objects which already exist in the parent ?

A. Yes, but. The changes _do_ get pased back up to the parent, but they are not the same object. Each EO instance lives in one and only one editing context. So the new object in defaultEditingContext() will have the same values and same global ID as the object in childEditingContext. BUT and this is a big BUT it is NOT the same Java object. That is, the objects are equivalent but not ==. They are the same conceptual object but not the same physical object.

If you are returning to a previous page with a list showing a list of items in defaultEditingContext(), you need to use EOUtilities.localnstanceOfObject(defaultEditingContext(), addedEOInChildEC) to get an EO that you can add to the list.

Q. I still have trouble getting all those objects right. i.e. that there is only one instance of a Object from the database per EODatastore, but each Editing-Context for that datastore has its own version of the object. Is that the case ?

A. It is a little hard to grasp. There is only one conceptual object. There is only one object in the Object Store (aka EODatabase). And there is absolutely only a single row in the database (well, ignoring Vertical inheritance but let's not drag that in). Except that it is not really an object as it has only data and no behavior. You will usually hear this referred to as the "snapshot".

Here comes the confusing part. To actually do something useful with one of these alleged objects, you need to instantiate it as an EOEnterpriseObject ( aka EOGenericRecord, EOCustomObject, or subclass). These aren't really the object either. They are more like a Facade. They have the missing behavior, but lack the data. While they _appear_ to have the data, they actually only have references to the data in the snapshot. These EOEnterpriseObjects must live in an EOEditingContext. There can be many of them (one for each EC), but they all reference the same data in the snapshot. Only when changes are made do they hold data, and just the changed data. When one of these objects change and then get saved, this updates the snapshot and all the other versions can see the updated data as well.

Note that the phrase "... can see the updated data as well." is distinct from the phrase "...will see the updated data as well." In particular, they won't see any changes in attributes that they have also just changed. This is why he said, "Only when changes are made do they hold data, and just the changed data."

In particular, say you updated a Person EO for Sally Smith in your editing context by changing only her lastName attribute to "Jones" without savingChanges. Say someone else in another editing context also updated Sally Smith's lastName attribute to "Brown" but also updated her age from 26 to 27 and savedChanges on his editing context.

If you then took another look at your Sally Smith EO. You would see that her age had changed (from 26 to 27) since you hadn't touched the age attribute, but you would still see that her lastName was "Jones" as you had last set it, because the lastName attribute of your Sally Smith nee Jones nee Brown EO no longer references the lastName attribute in the snapshot but rather references the local String that you provided to change it.

Further, if you had marked the Locking characteristic for the lastName attribute of Person in your EOModel, then when you tried to save changes, EOF would throw an exception indicating that it couldn't update the record. Though it's seldom obvious to the newcomer, this is an optimistic locking exception and says that someone changed the EO under you (that is, after you read it and before you updated it).

(with thanks to Jerry Walker for the last bit)