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 05:20  |
Eclipse User |
|
|
|
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 05:41] by Moderator |
|
| | |
| Re: EVM: Update job - How to find the element that changed? [message #1696312 is a reply to message #1696311] |
Mon, 25 May 2015 09:50  |
| Eclipse User |
|
|
|
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 18:23 |
| Eclipse User |
|
|
|
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 #1698791 is a reply to message #1698098] |
Wed, 17 June 2015 17:46 |
| Eclipse User |
|
|
|
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 Jul 26 15:09:17 EDT 2025
Powered by FUDForum. Page generated in 0.04989 seconds |
Home