search

eMoflon / emoflon-ibex

Shared, eMoflon-specific component for incremental unidirectional and bidirectional graph transformations
GNU General Public License v3.0
13 stars 4 forks source link

Democles Demo #104

Closed anthonyanjorin closed 7 years ago

anthonyanjorin commented 7 years ago

Hi @gervarro,

after spending a few hours trying to understand the trainbenchmark (and getting the incr. PM to run for my example based on it) I've basically given up.

I've started a minimal example here: https://github.com/eMoflon/emoflon-ibex/tree/democlesTrial and have added some todos for you.

Basically, all I want to understand for the moment is the initialisation code required to get the incremental pattern matcher up and running with minimal effort. All I need for the moment is to be able to then react to the matches found.

In the project there are trivial source, target and correspondence metamodels under /model. Under /instance there is a trivial input model basically consisting of exactly one source element.

I have also specified a very simple pattern that should match for exactly this source element, i.e., in this example a match should be found and I want to react to it by applying a forward rule (and creating the corresponding target element).

Thanks for your help! Tony

gervarro commented 7 years ago

One more thing: EMF handles those cases rather unreliably (from an incremental point of view) when you simply set the container of an EObject. EMF produces different sets of notifications depending on whether you trigger the same insertion / container edge creation at the parent (container) or at the child (contained node) :wink:.

anthonyanjorin commented 7 years ago

Thanks, Greg.

We'll try to think of a way of avoiding this. For example a temporary container should be feasible. That way we could avoid placing objects directly in a resource, and if a real parent is set later the object should hop out of the temp container automatically.

At the end of the process the temp container should have in most cases exactly one root. If it has multiple roots then the TGG is a bit exotic (but this can be the case in general) and the user can be expected to handle this case (which is analogous to having multiple contents in the same resource).

gervarro commented 7 years ago

I will try to fix it in the notification processing layer.

Done (objects are now moved from the resource to the new container in a correct way). Fix available on the advanced update site.

anthonyanjorin commented 7 years ago

Great! Our model generator seems to be working perfectly now (for my simple example).

I think it's time to close this issue (Democles integration).

I can start working on the other scenarios (sync).

Cheers and thanks for the fast fixes, Tony