Provide "incremental update execution mode"

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 463554 | | Status | NEW | | Importance | P3 normal | | Reported | Mar 31, 2015 04:56 EDT | | Modified | Mar 31, 2015 08:09 EDT | | Version | 3.4 | | Depends on | 463555, 463572 | | Reporter | Sergey Boyko |

Description

From specification:\ Once a relationship (a set of trace instances) has been established between models by executing a transformation, small changes to a source model may be propagated to a target model by re-executing the transformation in the context of the trace, causing only the relevant target model elements to be changed, without modifying the rest of the model.

Таким образом реализовать возможность запускать преобразование в контексте существующих записей трассировки.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Mar 31, 2015 04:56

(In reply to Sergey Boyko from comment #0)

From specification: Once a relationship (a set of trace instances) has been established between models by executing a transformation, small changes to a source model may be propagated to a target model by re-executing the transformation in the context of the trace, causing only the relevant target model elements to be changed, without modifying the rest of the model.

Thus implement possibility to run transformation in context of existing trace records.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 31, 2015 05:12

I am just putting this support in for the QVTi execution that provides the backend for QVTr and QVTc. In a declarative context it's not that hard.

For QVTo it will be much more challenging. Actually it's impossible, unless you restrict your ambition as to what can be achieved. https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf gives some consideration of what restrictions may be appropriate.

Unless you have a simple way to do this now, I strongly recommend deferring this and instead contribute to the declarative formalisation of QVTo so that a QVTo2QVTi transformation can be used to exploit the declarative execution engine and its direct Java code generator.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Mar 31, 2015 08:09

(In reply to Ed Willink from comment #2)

I am just putting this support in for the QVTi execution that provides the backend for QVTr and QVTc. In a declarative context it's not that hard.

For QVTo it will be much more challenging. Actually it's impossible, unless you restrict your ambition as to what can be achieved. https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf gives some consideration of what restrictions may be appropriate.

Unless you have a simple way to do this now, I strongly recommend deferring this and instead contribute to the declarative formalisation of QVTo so that a QVTo2QVTi transformation can be used to exploit the declarative execution engine and its direct Java code generator.

Ed, thanks for information. \ I'm going to implement simple solution where all instances will be identified by addresses and deep clone will be used only for mutable Data Types (like List and Dict). Simple scenario is to re-execute the whole transformation in context of trace records so Global context / Transformation context changes are not relevant and will be taken into account automatically.\ More complex scenarios when the transformation will be a part of (semi-)automatic framework and execution is triggered by changes in input models will be considered later.