Creating contained objects with Epsilon does not work

[philip-iii]

New objects created with Epsilon are not stored / managed properly if they are contained in another object. In contrast, top-level elements that are not contained in another object can be instantiated and saved as intended.

Regardless of whether the Epsilon EMF API or the Epsilon Object Language is used, the results are identical.

A closer look at head to head comparison between an instance created with the Java EMF API and the Epsilon EMF API seems to indicate that the only difference is in the eStorage property of the instances, where the Epsilon EMF API appears to add extra information regarding ContainmentChangeListener which in turn potentially prevents NeoEMF from work properly. Not sure if this helps, perhaps the reason is also elsewhere.

Using Epsilon with a variety of other types of resources (XMI, binary, database via Teneo, Xtext, JSON) so far did not seem to cause any problems.

[gdaniel]

Hi Philip,

Indeed, eStorage may be related to your issue. I am not sure how it is handled by NeoEMF for the moment, I'll have a look. Are you still using the neo4j connector?

Could you put online (or send us a github URL) a sample code that reproduces your issue? It would help us a lot to fix your issue as fast as possible.

Thanks for sharing your issues with us.

Regards,

Gwendal

[philip-iii]

Hi Daniel,

thanks for the quick response, I've been rather busy with other stuff over the last couple of days, but I finally managed to upload an isolated example at https://github.com/philip-iii/NeoEpsilon. The readme should provide some information regarding the contents and how to use it to reproduce and investigate the issue. Let me know if you need any further information or additional examples.

I am using NeoEMF 1.0.0, as after trying to update to 1.0.1. I had some problems getting it to work which seemed related to the connector, but I did not have time to investigate that any further so I just reverted to 1.0.0. for the time being.

Cheers,

Philip

[gdaniel]

Hi Philip,

I am investigating your issue, for now I have isolated your problem and I found that the behavior of EOL regarding new objects emphasizes a consistency issue we never spotted in NeoEMF: if a new element is first added to the resource and then moved to its real container (which doesn't have a navigable opposite), the containment information is lost during the inverseAdd call. I have to check if this is specific to the Neo4j implementation or if this is bugged in each backend.

Btw, I am running your example on NeoEMF 1.0.2, but I don't think it matters a lot since I am able to reproduce your issue.

Cheers,

Gwendal

[philip-iii]

Thanks for looking into this! Let me know how it goes and if I can provide any additional help.

Is v1.0.2 already on the update site? It wasn't showing up the last time I checked.

Cheers,

Philip

[gdaniel]

Hi Philip,

I have found the problem, it is located at the core level. When a containment feature is updated EMF first add the element to its new container, then calls inverseAdd on the new object to remove the opposite reference to the old container, and set it to the new container.

In your example the box is first attached to the resource (because of the way EOL handles new objects), and then moved to its real container shelf. NeoEMF will first set the link between shelf and box, then the inverseAdd is called and box is removed from the resource, and it's container is set to shelf. This is where we lose information, because box is temporary in a transient state (with no resource), and setting its container doesn't set the opposite reference. This creates a consistency issue between the container and the contained object, where shelf.boxes->size() = 0 is true, but box.eContainer() also returns the correct container.

I have done a quick fix on this, I will run the benchmarks today to see if it is efficient (changing the core component often implies some weird side effects) and push it if everything is fine.

The update site on neoemf website contains v1.0.1, which is the latest stable release, you can find v1.0.2 here, please note this update site corresponds to the development branch, and is built after each commit so it can contains some issues. When the problem would be solved I'll send you a link to a stable 1.0.2 update site to avoid any problem.

Cheers,

Gwendal

[gdaniel]

Hi Philip,

I pushed a fix that solves your issue. I put a zipped snapshot of the update site on dropbox, please use this link instead of the one I gave you before to download it (I put a frozen version on dropbox because the update site built from master is not always stable).

After installing the update site you'll need to change the dependencies in your manifest by removing all the previous neoemf dependencies and adding fr.inria.atlanmod.neoemf.core, fr.inria.atlanmod.neoemf.data.blueprints.core, fr.inria.atlanmod.neoemf.data.blueprints.neo4j, fr.inria.atlanmod.neoemf.data.blueprints.neo4j.wrapper. You will also need to update the imports in your project.

If you experience any issue with this fix feel free to contact me.

Cheers,

Gwendal