DefaultPersistentEObject.eContainer is not efficient

[gdaniel]

Every call to eContainer is delegated to the internal EStore, even if the eContainer field contains the requested value. This creates a lot of unnecessary database calls, especially when an URI is computed from an EObject by navigating all its parents.

Note: fixing this may cause some unexpected side-effects, need to be carefull on resource setting and container consistency.

[gdaniel]

The eContainer field is now returned if it is set (we cannot know if a null value means there is no container or if it hasn't been loaded yet).
If the resource is using a distributed backend (see PersistenceBackend#isDistributed()) the value of the field is never returned: other clients may have updated it and it is required to check the database each time (see discussion with @amine-ben)

[abelgomez]

Hi all, let me participate in this discussion :)

Althought EMF does not specify its behaviour in concurrent/distributed environments, can't this enhancement be considered as a deviation from the expected behavior of the standard EMF API?

If this is the case, I think that it would be more reasonable to have such a feature disabled by default. Anyway, you can always provide the users the ability to enable this optimization via the options in the resource.load(Map <?,?> options) method, isn't it?

[abelgomez]

Ok, checking the code I see I didn't read your explanation carefully, @gdaniel . Sorry! :)

[gdaniel]

Hi Abel!

Sorry if the explanation was not clear :)
If the resource uses an embedded database it is safe to return the value of the eContainer field: it is updated at the same time in the database and in the PersistentEObject and we can use it as a cached value.

If the resource uses a distributed database then the value of this field cannot be trusted because another client may have updated it.

[abelgomez]

👍

Yes, hopefully I read the code because I got the wrong idea on my first read (my fault!). Sorry for the noise and thanks for your clarification! :)