Home » Archived » EMF-IncQuery » EVM: Update job - How to find the element that changed?
| EVM: Update job - How to find the element that changed? [message #1696284] |
Mon, 25 May 2015 09:20  |
 ihave question
Messages: 32
Registered: November 2014 |
Member |
|
|
Hello! The idea to incrementally maintain mappings with the EVM is very interesting and I implemented a small framework on top of it.
The problem is that every time the update job is called, I'm at a loss to tell which element within my match set changed as to cause a rule activation.
In simple patterns this might be ok, but in my case the domain objects feature many properties (which need to be scanned for changes) and I have to reconstruct & reanalyse a graph each time one source element changes
Would it be possible to deliver (together with the update activation) the underlying EMF notification or delta/changeset?
This would also be of interest for complex transformations, as one would not need to search/remap already mapped elements, i.e.. just to change a label ....
[Updated on: Mon, 25 May 2015 09:41] Report message to a moderator |
|
| |
| Re: EVM: Update job - How to find the element that changed? [message #1696311 is a reply to message #1696291] |
Mon, 25 May 2015 13:35  |
ihave question
Messages: 32
Registered: November 2014 |
Member |
|
|
I am aware of the Job<M> class and even use the generated match processors which hand over the typed and bound parameters.
My problem is that I don't know which parameters were changed when the update job is called so I have to detach the view, re-parse every String, transform that to an AST, reindex the called variables and reattach the view.
In model transformations, the same applies: I don't know which parameter changed, so i have to map all parameters to the target domain again, which causes several other rule activations down the transformation chain (which also don't know which bound parameter changed).
Because of this (for me at least) the update method is almost like the appear job
[Updated on: Mon, 25 May 2015 13:38] Report message to a moderator |
|
|
| Re: EVM: Update job - How to find the element that changed? [message #1696312 is a reply to message #1696311] |
Mon, 25 May 2015 13:50 |
Zoltan Ujhelyi
Messages: 392
Registered: July 2015 |
Senior Member |
|
|
Hi,
I see, sorry for my unusable answer before; I have misunderstood your question.
Currently, EVM does not support sending these notifications you require, but you could manage the required traces in different ways:
(1) If you have an EMF model for your target, you could write traceability patterns that connect your source and target models, and use that to find out whether a target instance needs to be updated.
(2) Your job can cache the required data keyed with the activation. If the activation changed, you can find out which parameters are updated. In this case, you probably have to provide your own Job implementation (instead of the stateless job using match processors).
Cheers,
Zoltán
|
|
| |
| Re: EVM: Update job - How to find the element that changed? [message #1696343 is a reply to message #1696342] |
Mon, 25 May 2015 22:23 |
Zoltan Ujhelyi
Messages: 392
Registered: July 2015 |
Senior Member |
|
|
Hi,
if I understood your question, you want to know how we make sure that edges/containment references are deleted if one of its endpoints are removed. To support such cases, two approaches are possible:
(1) You can provide patterns that connect source and target model elements, and then use these traceability patterns to initialize the rules. This approach makes sure that the existence of traceability links in rules; and simply removes the activation if these traceability links are not present anymore.
(2) Provide a conflict resolver that gives precedence to end point creation over reference creation (more specifically, the order is edge deletion < item deletion < item creation < edge creation); for this implementation see the InvertedDisappearancePriorityConflictResolver class - available in recent builds of IncQuery).
Traditionally, we were using the second option, but after a recent rewrite the first one is used, with dedicated traceability patterns (see http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/tree/plugins/org.eclipse.incquery.viewers.runtime/src/org/eclipse/incquery/viewers/runtime/model/patterns/traceability.eiq). In our experience, the first approach is more stable, but requires (1) a bigger implementation effort and (2) the patterns become harder to understand/reuse.
Cheers,
Zoltán
|
|
|
| Re: EVM: Update job - How to find the element that changed? [message #1698098 is a reply to message #1696343] |
Thu, 11 June 2015 08:32 |
ihave question
Messages: 32
Registered: November 2014 |
Member |
|
|
Just a follow up question:
I'm interested in both creating and removing edges/containment references. And you're right traceability is quite a nasty business as long as it cannot be automated. So if I'm to take the second approach I'd end up with a priority scheduler like this: containment/parents first > items second (because their parent are already transformed) > edges between items
But how do I order the containment tree transform? I believe there are no control statements as apposed to other transformation languages?
Because, Imagine that A contains B contains C. As the rules are unordered, smth. like this could happen:
fire C -> B not transformed!
fire B -> A not transformed!
fire A -> transform to A*
But now all rules have been fired and only A was transformed
So Ideally i'd have to map A first, B second and C third which leads to a kind of recursive/sequential rule, so we'd again need traceability links to keep a record of transformed/untransformed nodes.
Another possibility were to specify a rule with a "UnmappedTopParent" that transforms containers without a parent (== null) and mark it as mapped. That rule would then move down the tree sequentially right?
So we get
A > B > C > items contained in A, B, C > edges between items
Is there anything like a control statement procedure in IQ/Viatra?
Will there be automated traceability structures in IQ/Viatra?
Thanks.
[Updated on: Thu, 11 June 2015 08:34] Report message to a moderator |
|
|
| Re: EVM: Update job - How to find the element that changed? [message #1698791 is a reply to message #1698098] |
Wed, 17 June 2015 21:46 |
Zoltan Ujhelyi
Messages: 392
Registered: July 2015 |
Senior Member |
|
|
Hi,
first of all, sorry for the slow answer, I somehow lost this post last week.
You are right, there are no direct control statements in EVM, as it is based on rule execution. However, there are various ways to express ordering constraints between transformation rules:
1. If the rule B has a precondition that A* must exist before it is executed, it will not be allowed before A is executed. Basically, this orders the rules based on data/model dependencies.
2. If you have multiple rules available for firing, you can define a ConflictResolver where a strategy can be defined for ordering the activations. Some ConflictResolvers are already implemented, including rule priority based ones.
3. Finally, VIATRA has a batch transformation API over EVM (see https://wiki.eclipse.org/VIATRA/Transformation_API#Batch_Transformation_API). In that case, the trick is turn off automatic rule execution, but allow manual firing of the rules. This way, it is possible to still provide transformation rules, but reuse them in a more usual, imperative style code. This is somewhat hard to program manually over EVM, but the VIATRA batch transformation API hides most of the underlying stuff.
Which one to choose? It depends on your larger application. The VIATRA batch API is the closest one to the usual programming paradigms, thus it is easiest to learn, however, it does not allow easy future updates, such as incremental updates when the source models change, etc. Both priorities and data dependencies are harder to write at first, but as the rules consider the local aspects, adding new conditions/cases is usually simple, and incremental execution is also possible.
Traceability structures: we have experimented a lot with traceability models, and we have some ideas how to support them (e.g. the new Viewers framework uses an automatically generated traceability model between the source model and the derived view model), but we have no easily reusable solution yet. In the future, we will surely work on this aspect as well, but at this moment I cannot provide you a timeframe.
I hope, this was helpful.
Cheers,
Zoltán
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:41:19 GMT 2024
Powered by FUDForum. Page generated in 0.04096 seconds |
] 
Search
Help
Register
Login
Home
