Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » Incremental transformation not working because input traces are ignored
Incremental transformation not working because input traces are ignored [message #1735418] Sat, 18 June 2016 23:23 Go to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1165
Registered: July 2009
Location: Canada
Senior Member

Hi,

It appears that incremental transformation support was implemented in
the Mars release using a new Trace utility class and related IContext.
Together, these are supposed to allow a client to inject Traces
obtained from a previous transformation execution into a
TransformationExecutor for the next transformation, so that the latter
can find traceability of mappings from the previous transformation.

However, I am unable to get it to work. I create an EvaluationContext
and set a Trace object into the session data and then I see that
execution of a transformation puts all of its traces into that Trace
object for me. So far, so good.

Now, when I take this resulting Trace object and set it into the
EvaluationContext of the transformation, it is completely ignored, and
the output traces are just the traces for mappings evaluated by the
second transformation.

The problem seems to be that in the
QVTOperationalEvaluationEnv.RootInternal class, the constructor just
ignores the incoming Trace object in the IContext:

RootInternal(IContext context) {
assert context != null;
myContext = context;
myIsDeferredExecution = false;
myTraces = TraceFactory.eINSTANCE.createTrace();
}

See how 'myTraces' is just created new, instead of being taken from the
context.

Is there something else that I should be doing to make incremental
transformations based on previous traces work? Any example code that I
can be directed to look at?

Thanks,

Christian
Re: Incremental transformation not working because input traces are ignored [message #1735427 is a reply to message #1735418] Sun, 19 June 2016 10:07 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5640
Registered: July 2009
Senior Member
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Christian<br>
<br>
After leaving traceability issues deferred in QVT 1.2, I
summarized my thoughts in [1] <cite class="_Rm"></cite>sadly the
paper wasn't accepted. Subsequently, while resolving issues for
QVT 1.3, the paper formed the basis for an invited talk at AMT
2015 [2]. While preparing the camera ready copy, I finally
realized that the whole thing was based on an ambiguous fallacy
and withdrew the paper and wrote:<br>
<br>
<i>QVT 1.3 8.1.11.8 Persisted Trace Data</i><i><br>
</i><i>The trace-data may be persisted and reloaded to support a
re-execution. However the trace-record does not trace</i><i><br>
</i><i>configuration data, transformation properties or
intermediate data, and does not involve a deep clone of every
traced</i><i><br>
</i><i>object. It is therefore not possible to use a persisted
form of the trace-data to support incremental re-execution of an</i><i><br>
</i><i>arbitrary QVTo transformation since the required object
state may not be present in persisted trace. A well-behaved</i><i><br>
</i><i>transformation that avoids dependence on mutable object
properties or other untraced facilities may be re-executable.</i><br>
<br>
The problem is that QVT just claims that the trace is language
agnostic and useful.<br>
<br>
QVTo and QVTc are very different so the specification that QVTo
reuses QVTc's trace is ridiculous. Eclipse QVTo has its own trace.<br>
<br>
An internal trace is necessary for inter mapping object re-use.
QVT 1.3 adds clarifying detail wrt polymorphic dispatch tracing
which Eclipse QVTo has yet to catch up on.<br>
<br>
A persisted trace may be useful for:<br>
<br>
a) debugging - easy<br>
<br>
b) incremental re-execution - aargh!<br>
<br>
For QVTo where a badly written mapping may be making incremental
changes to a Dict, a clone of every state of the Dict must be
separately persisted to support correct re-execution. This is very
difficult to achieve without unacceptable quadratic or worse
costs. Synchromnization of numerous clones is also challenging.<br>
<br>
Bottom line. Incremental QVTo execution is only feasible for
well-behaved transformations and IMHO such well-behaved
transformations are candidates for automated meta-transformation
to a more disciplined QVTc/QVTr form. (There are now working QVTc
and QVTr examples in the Neon release of Eclipse QVTd that
demonstrate a 30-fold speed-up with respect to QVTo through the
use of auto-generated Java rather than interpreted execution.
However Eclipse QVTd remains at 0.13.0 rather than 1.0.0 since the
reliability of the compilation is only fit for research purposes.)<br>
<br>
If the experimental incremental QVTo works for you, great. If not,
may be you can fix it, but fundamentally it can never hope to
address more than very well-behaved QVTo. The most obvious
deficiency that I am aware of is that it only traces what
happened. It does not trace what did not happen, so if an
incremental condition changes guard results, previously
unperformed executions are not executed.<br>
<br>
Yet further problems in <a class="moz-txt-link-freetext" href="http://issues.omg.org/browse/QVT14-15">http://issues.omg.org/browse/QVT14-15</a><br>
<br>
    Regards<br>
<br>
        Ed Willink<br>
<br>
<br>
[1] <cite class="_Rm"><a class="moz-txt-link-freetext" href="https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf">https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf</a></cite><br>
<br>
[2]
<a class="moz-txt-link-freetext" href="http://www.slideshare.net/EdWillink/qvt-traceability-what-does-it-really-mean">http://www.slideshare.net/EdWillink/qvt-traceability-what-does-it-really-mean</a><br>
<br>
On 19/06/2016 00:23, Christian W. Damus wrote:<br>
</div>
<blockquote cite="mid:nk4l58$fes$1@xxxxxxxxe.org" type="cite">Hi,
<br>
<br>
It appears that incremental transformation support was implemented
in the Mars release using a new Trace utility class and related
IContext.  Together, these are supposed to allow a client to
inject Traces obtained from a previous transformation execution
into a TransformationExecutor for the next transformation, so that
the latter can find traceability of mappings from the previous
transformation.
<br>
<br>
However, I am unable to get it to work.  I create an
EvaluationContext and set a Trace object into the session data and
then I see that execution of a transformation puts all of its
traces into that Trace object for me.  So far, so good.
<br>
<br>
Now, when I take this resulting Trace object and set it into the
EvaluationContext of the transformation, it is completely ignored,
and the output traces are just the traces for mappings evaluated
by the second transformation.
<br>
<br>
The problem seems to be that in the
QVTOperationalEvaluationEnv.RootInternal class, the constructor
just ignores the incoming Trace object in the IContext:
<br>
<br>
        RootInternal(IContext context) {
<br>
            assert context != null;
<br>
            myContext = context;
<br>
            myIsDeferredExecution = false;
<br>
            myTraces = TraceFactory.eINSTANCE.createTrace();
<br>
        }
<br>
<br>
See how 'myTraces' is just created new, instead of being taken
from the context.
<br>
<br>
Is there something else that I should be doing to make incremental
transformations based on previous traces work?  Any example code
that I can be directed to look at?
<br>
<br>
Thanks,
<br>
<br>
Christian
<br>
<br>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>
Re: Incremental transformation not working because input traces are ignored [message #1735495 is a reply to message #1735427] Mon, 20 June 2016 11:34 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1165
Registered: July 2009
Location: Canada
Senior Member

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="Content-Style-Type" content="text/css">
<title></title>
<meta name="Generator" content="Cocoa HTML Writer">
<meta name="CocoaVersion" content="1404.47">
<style type="text/css">
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 14.0px Helvetica}
p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 14.0px Helvetica; min-height: 17.0px}
p.p3 {margin: 0.0px 0.0px 0.0px 12.0px; line-height: 18.0px; font: 16.0px Helvetica; color: #011892; -webkit-text-stroke: #000000}
p.p4 {margin: 0.0px 0.0px 0.0px 12.0px; line-height: 18.0px; font: 16.0px Helvetica; color: #011892; -webkit-text-stroke: #000000; min-height: 19.0px}
p.p5 {margin: 0.0px 0.0px 0.0px 12.0px; line-height: 18.0px; font: 16.0px Helvetica; color: #011892; -webkit-text-stroke: #0000ee}
p.p6 {margin: 0.0px 0.0px 16.0px 12.0px; line-height: 18.0px; font: 16.0px Helvetica; color: #011892; -webkit-text-stroke: #000000}
p.p7 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 17.0px; font: 14.0px Helvetica; min-height: 17.0px}
span.s1 {font-kerning: none}
span.s2 {font-kerning: none; -webkit-text-stroke: 0px #000000}
span.s3 {text-decoration: underline ; font-kerning: none; -webkit-text-stroke: 0px #0000ee}
</style>
</head>
<body>
<p class="p1">Hi, Ed,</p>
<p class="p2"><br></p>
<p class="p1">Yes, for my use case (model import from RSA-RTE to Papyrus-RT), it is sufficient that the trace only record mappings:<span class="Apple-converted-space">  </span>which output was generated from what input.<span class="Apple-converted-space">  </span>In my particular case, I have an extension in Papyrus-RT of the basic model import from RSA that is implemented in Papyrus.<span class="Apple-converted-space">  </span>So the "incremental" transformation is just a re-processing of some outputs (diagrams for now) to tweak them for pecularities of the Papyrus-RT implementation of UML-RT.</p>
<p class="p2"><br></p>
<p class="p1">My core need at the moment is just for a transformation executed in a Papyrus-RT extension of the pipeline to be able to query the traces to find which diagram in the RSA model generated a particular diagram in the Papyrus model, using the invresolve operation.</p>
<p class="p2"><br></p>
<p class="p1">If I provide a patch for QVTo, who will be available to review it?<span class="Apple-converted-space">  </span>I'm not sure who is now active on the committer team.</p>
<p class="p2"><br></p>
<p class="p1">Thanks,</p>
<p class="p2"><br></p>
<p class="p1">Christian</p>
<p class="p2"><br></p>
<p class="p2"><br></p>
<p class="p1">On 2016-06-19 10:07:45 +0000, Ed Willink said:</p>
<p class="p2"><br></p>
<p class="p3"><span class="s1">Hi Christian</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">After leaving traceability issues deferred in QVT 1.2, I summarized my thoughts in [1] sadly the paper wasn't accepted. Subsequently, while resolving issues for QVT 1.3, the paper formed the basis for an invited talk at AMT 2015 [2]. While preparing the camera ready copy, I finally realized that the whole thing was based on an ambiguous fallacy and withdrew the paper and wrote:</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">QVT 1.3 8.1.11.8 Persisted Trace Data</span></p>
<p class="p3"><span class="s1">The trace-data may be persisted and reloaded to support a re-execution. However the trace-record does not trace</span></p>
<p class="p3"><span class="s1">configuration data, transformation properties or intermediate data, and does not involve a deep clone of every traced</span></p>
<p class="p3"><span class="s1">object. It is therefore not possible to use a persisted form of the trace-data to support incremental re-execution of an</span></p>
<p class="p3"><span class="s1">arbitrary QVTo transformation since the required object state may not be present in persisted trace. A well-behaved</span></p>
<p class="p3"><span class="s1">transformation that avoids dependence on mutable object properties or other untraced facilities may be re-executable.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">The problem is that QVT just claims that the trace is language agnostic and useful.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">QVTo and QVTc are very different so the specification that QVTo reuses QVTc's trace is ridiculous. Eclipse QVTo has its own trace.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">An internal trace is necessary for inter mapping object re-use. QVT 1.3 adds clarifying detail wrt polymorphic dispatch tracing which Eclipse QVTo has yet to catch up on.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">A persisted trace may be useful for:</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">a) debugging - easy</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">b) incremental re-execution - aargh!</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">For QVTo where a badly written mapping may be making incremental changes to a Dict, a clone of every state of the Dict must be separately persisted to support correct re-execution. This is very difficult to achieve without unacceptable quadratic or worse costs. Synchromnization of numerous clones is also challenging.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">Bottom line. Incremental QVTo execution is only feasible for well-behaved transformations and IMHO such well-behaved transformations are candidates for automated meta-transformation to a more disciplined QVTc/QVTr form. (There are now working QVTc and QVTr examples in the Neon release of Eclipse QVTd that demonstrate a 30-fold speed-up with respect to QVTo through the use of auto-generated Java rather than interpreted execution. However Eclipse QVTd remains at 0.13.0 rather than 1.0.0 since the reliability of the compilation is only fit for research purposes.)</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">If the experimental incremental QVTo works for you, great. If not, may be you can fix it, but fundamentally it can never hope to address more than very well-behaved QVTo. The most obvious deficiency that I am aware of is that it only traces what happened. It does not trace what did not happen, so if an incremental condition changes guard results, previously unperformed executions are not executed.</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p5"><span class="s2">Yet further problems in <a href="http://issues.omg.org/browse/QVT14-15"><span class="s3">http://issues.omg.org/browse/QVT14-15</span></a></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">    Regards</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">        Ed Willink</span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p5"><span class="s2">[1] <a href="https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf"><span class="s3">https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf</span></a></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p5"><span class="s2">[2] <a href="http://www.slideshare.net/EdWillink/qvt-traceability-what-does-it-really-mean"><span class="s3">http://www.slideshare.net/EdWillink/qvt-traceability-what-does-it-really-mean</span></a></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">On 19/06/2016 00:23, Christian W. Damus wrote:</span></p>
<p class="p3"><span class="s1">Hi,<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">It appears that incremental transformation support was implemented in the Mars release using a new Trace utility class and related IContext.  Together, these are supposed to allow a client to inject Traces obtained from a previous transformation execution into a TransformationExecutor for the next transformation, so that the latter can find traceability of mappings from the previous transformation.<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">However, I am unable to get it to work.  I create an EvaluationContext and set a Trace object into the session data and then I see that execution of a transformation puts all of its traces into that Trace object for me.  So far, so good.<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">Now, when I take this resulting Trace object and set it into the EvaluationContext of the transformation, it is completely ignored, and the output traces are just the traces for mappings evaluated by the second transformation.<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">The problem seems to be that in the QVTOperationalEvaluationEnv.RootInternal class, the constructor just ignores the incoming Trace object in the IContext:<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">        RootInternal(IContext context) {<span class="Apple-converted-space"> </span></span></p>
<p class="p3"><span class="s1">            assert context != null;<span class="Apple-converted-space"> </span></span></p>
<p class="p3"><span class="s1">            myContext = context;<span class="Apple-converted-space"> </span></span></p>
<p class="p3"><span class="s1">            myIsDeferredExecution = false;<span class="Apple-converted-space"> </span></span></p>
<p class="p3"><span class="s1">            myTraces = TraceFactory.eINSTANCE.createTrace();<span class="Apple-converted-space"> </span></span></p>
<p class="p3"><span class="s1">        }<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">See how 'myTraces' is just created new, instead of being taken from the context.<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">Is there something else that I should be doing to make incremental transformations based on previous traces work?  Any example code that I can be directed to look at?<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">Thanks,<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p3"><span class="s1">Christian<span class="Apple-converted-space"> </span></span></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p4"><span class="s1"></span><br></p>
<p class="p6"><span class="s1"><br>
</span></p>
<p class="p7"><br></p>
</body>
</html>
Re: Incremental transformation not working because input traces are ignored [message #1735498 is a reply to message #1735495] Mon, 20 June 2016 11:59 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5640
Registered: July 2009
Senior Member
Hi Christian

Sergey and Christopher are active on the current code base. My activity
is mostly in discussions, future Pivot-based QVT. Adolfo is working on
auto-generation of the OCL / QVT CS2AS and Xtext-based QVTo.

The experimental incremental execution is Sergey's work and he usually
reviews moderately quickly.

However since the experiment has significant limitations, I doubt that
it will ever be more than experimental. Perhaps fixing it will do for
you today so that you can migrate to incremental QVTc/QVTr for Oxygen.

Regards

Ed Willink


On 20/06/2016 12:34, Christian W. Damus wrote:
>
> Hi, Ed,
>
>
> Yes, for my use case (model import from RSA-RTE to Papyrus-RT), it is
> sufficient that the trace only record mappings:which output was
> generated from what input.In my particular case, I have an extension
> in Papyrus-RT of the basic model import from RSA that is implemented
> in Papyrus.So the "incremental" transformation is just a re-processing
> of some outputs (diagrams for now) to tweak them for pecularities of
> the Papyrus-RT implementation of UML-RT.
>
>
> My core need at the moment is just for a transformation executed in a
> Papyrus-RT extension of the pipeline to be able to query the traces to
> find which diagram in the RSA model generated a particular diagram in
> the Papyrus model, using the invresolve operation.
>
>
> If I provide a patch for QVTo, who will be available to review it?I'm
> not sure who is now active on the committer team.
>
>
> Thanks,
>
>
> Christian
>
>
>
> On 2016-06-19 10:07:45 +0000, Ed Willink said:
>
>
> Hi Christian
>
>
> After leaving traceability issues deferred in QVT 1.2, I summarized my
> thoughts in [1] sadly the paper wasn't accepted. Subsequently, while
> resolving issues for QVT 1.3, the paper formed the basis for an
> invited talk at AMT 2015 [2]. While preparing the camera ready copy, I
> finally realized that the whole thing was based on an ambiguous
> fallacy and withdrew the paper and wrote:
>
>
> QVT 1.3 8.1.11.8 Persisted Trace Data
>
> The trace-data may be persisted and reloaded to support a
> re-execution. However the trace-record does not trace
>
> configuration data, transformation properties or intermediate data,
> and does not involve a deep clone of every traced
>
> object. It is therefore not possible to use a persisted form of the
> trace-data to support incremental re-execution of an
>
> arbitrary QVTo transformation since the required object state may not
> be present in persisted trace. A well-behaved
>
> transformation that avoids dependence on mutable object properties or
> other untraced facilities may be re-executable.
>
>
> The problem is that QVT just claims that the trace is language
> agnostic and useful.
>
>
> QVTo and QVTc are very different so the specification that QVTo reuses
> QVTc's trace is ridiculous. Eclipse QVTo has its own trace.
>
>
> An internal trace is necessary for inter mapping object re-use. QVT
> 1.3 adds clarifying detail wrt polymorphic dispatch tracing which
> Eclipse QVTo has yet to catch up on.
>
>
> A persisted trace may be useful for:
>
>
> a) debugging - easy
>
>
> b) incremental re-execution - aargh!
>
>
> For QVTo where a badly written mapping may be making incremental
> changes to a Dict, a clone of every state of the Dict must be
> separately persisted to support correct re-execution. This is very
> difficult to achieve without unacceptable quadratic or worse costs.
> Synchromnization of numerous clones is also challenging.
>
>
> Bottom line. Incremental QVTo execution is only feasible for
> well-behaved transformations and IMHO such well-behaved
> transformations are candidates for automated meta-transformation to a
> more disciplined QVTc/QVTr form. (There are now working QVTc and QVTr
> examples in the Neon release of Eclipse QVTd that demonstrate a
> 30-fold speed-up with respect to QVTo through the use of
> auto-generated Java rather than interpreted execution. However Eclipse
> QVTd remains at 0.13.0 rather than 1.0.0 since the reliability of the
> compilation is only fit for research purposes.)
>
>
> If the experimental incremental QVTo works for you, great. If not, may
> be you can fix it, but fundamentally it can never hope to address more
> than very well-behaved QVTo. The most obvious deficiency that I am
> aware of is that it only traces what happened. It does not trace what
> did not happen, so if an incremental condition changes guard results,
> previously unperformed executions are not executed.
>
>
> Yet further problems in http://issues.omg.org/browse/QVT14-15
>
>
> Regards
>
>
> Ed Willink
>
>
>
> [1] https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf
>
>
> [2]
> http://www.slideshare.net/EdWillink/qvt-traceability-what-does-it-really-mean
>
>
> On 19/06/2016 00:23, Christian W. Damus wrote:
>
> Hi,
>
>
> It appears that incremental transformation support was implemented in
> the Mars release using a new Trace utility class and related IContext.
> Together, these are supposed to allow a client to inject Traces
> obtained from a previous transformation execution into a
> TransformationExecutor for the next transformation, so that the latter
> can find traceability of mappings from the previous transformation.
>
>
> However, I am unable to get it to work. I create an EvaluationContext
> and set a Trace object into the session data and then I see that
> execution of a transformation puts all of its traces into that Trace
> object for me. So far, so good.
>
>
> Now, when I take this resulting Trace object and set it into the
> EvaluationContext of the transformation, it is completely ignored, and
> the output traces are just the traces for mappings evaluated by the
> second transformation.
>
>
> The problem seems to be that in the
> QVTOperationalEvaluationEnv.RootInternal class, the constructor just
> ignores the incoming Trace object in the IContext:
>
>
> RootInternal(IContext context) {
>
> assert context != null;
>
> myContext = context;
>
> myIsDeferredExecution = false;
>
> myTraces = TraceFactory.eINSTANCE.createTrace();
>
> }
>
>
> See how 'myTraces' is just created new, instead of being taken from
> the context.
>
>
> Is there something else that I should be doing to make incremental
> transformations based on previous traces work? Any example code that
> I can be directed to look at?
>
>
> Thanks,
>
>
> Christian
>
>
>
>
>
Re: Incremental transformation not working because input traces are ignored [message #1735531 is a reply to message #1735418] Mon, 20 June 2016 19:51 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1165
Registered: July 2009
Location: Canada
Senior Member

As it turns out, having prototyped a simple change that satisfies my
use case, I'm not sure that this is a change worth pursuing in QVTo for
my purposes.

I spent some time looking through the existing JUnit tests to see how
to build a regression test for my changes, and of course I saw the
tests that cover the incremental transformation feature implemented in
Mars. And digging deeper to see why those tests pass it became
apparent that there are two quite different ways in which traces are
used by the QVTo TransformationExecutor. These two different ways are
illustrated in the evaluation-visitor's handling of mapping operations:

* a trace found in the executor's current output trace model completely
short-circuits the mapping execution, immediately returning a
found-in-trace result

* a trace found in the IContext trace model supplied by the application
from a previous transformation half short-circuits the mapping
execution. The mapping result is not re-created, instead re-used from
before, but the rest of the mapping execution is still done, including
(AFAICT) executing the mapping body on the pre-existing result, putting
the pre-existing result into the extent, and adding a trace to the
current output trace model so that subsequent evaluations will
short-circuit completely as above

My "fix" for my scenario basically initialized the transaction
executor's output trace (in the evaluation environment) as a copy of
the incoming trace model supplied by the application from the previous
execution. This caused a bunch of test cases to fail because now they
were short-circuiting in the wrong way, such that output extents were
not being populated that should have been. Clearly, that's not good.

So, what this means is that the trace model supplied by the application
can only implement incremental evaluation of mapping rules. It cannot
be queried by a mapping using the invresolve and invresolveIn
operations, which only look at the output trace model, not the input
traces. And I don't want to start fiddling with those operations,
because that would probably break even more stuff.

So, for my purposes, I've found another solution to my original problem
that doesn't require changing how the trace history is used by the
evaluation environment. If I ever find another problem that can't
reasonably be addressed another way, I may have to revisit this
trace-model business and will almost certainly need help from the QVTo
committer team.

Thanks,

Christian


On 2016-06-18 23:23:20 +0000, Christian W. Damus said:

> Hi,
>
> It appears that incremental transformation support was implemented in
> the Mars release using a new Trace utility class and related IContext.
> Together, these are supposed to allow a client to inject Traces
> obtained from a previous transformation execution into a
> TransformationExecutor for the next transformation, so that the latter
> can find traceability of mappings from the previous transformation.
>
> However, I am unable to get it to work. I create an EvaluationContext
> and set a Trace object into the session data and then I see that
> execution of a transformation puts all of its traces into that Trace
> object for me. So far, so good.
>
> Now, when I take this resulting Trace object and set it into the
> EvaluationContext of the transformation, it is completely ignored, and
> the output traces are just the traces for mappings evaluated by the
> second transformation.
>
> The problem seems to be that in the
> QVTOperationalEvaluationEnv.RootInternal class, the constructor just
> ignores the incoming Trace object in the IContext:
>
> RootInternal(IContext context) {
> assert context != null;
> myContext = context;
> myIsDeferredExecution = false;
> myTraces = TraceFactory.eINSTANCE.createTrace();
> }
>
> See how 'myTraces' is just created new, instead of being taken from the
> context.
>
> Is there something else that I should be doing to make incremental
> transformations based on previous traces work? Any example code that I
> can be directed to look at?
>
> Thanks,
>
> Christian
Re: Incremental transformation not working because input traces are ignored [message #1735583 is a reply to message #1735418] Tue, 21 June 2016 10:36 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 171
Registered: July 2009
Senior Member
Hello Christian,

Christian W. Damus wrote on Sat, 18 June 2016 19:23
Hi,

It appears that incremental transformation support was implemented in
the Mars release using a new Trace utility class and related IContext.
Together, these are supposed to allow a client to inject Traces
obtained from a previous transformation execution into a
TransformationExecutor for the next transformation, so that the latter
can find traceability of mappings from the previous transformation.

However, I am unable to get it to work. I create an EvaluationContext
and set a Trace object into the session data and then I see that
execution of a transformation puts all of its traces into that Trace
object for me. So far, so good.

Now, when I take this resulting Trace object and set it into the
EvaluationContext of the transformation, it is completely ignored, and
the output traces are just the traces for mappings evaluated by the
second transformation.


I'm not quite understand your scenario.
Looks like you're trying to use 'Trace' object from one evaluation result as the incremental update trace for the other evaluation.

Note that each trace record is identified with fully qualified name which includes not only mapping name itself but also the name of transformation module. So it's impossible to use the trace created for one transformation as the input for the different transformation (even in case these transformations contain mappings with equal signatures).


Quote:

The problem seems to be that in the
QVTOperationalEvaluationEnv.RootInternal class, the constructor just
ignores the incoming Trace object in the IContext:

RootInternal(IContext context) {
assert context != null;
myContext = context;
myIsDeferredExecution = false;
myTraces = TraceFactory.eINSTANCE.createTrace();
}

See how 'myTraces' is just created new, instead of being taken from the
context.


Constructor of 'RootInternal class' quoted above initializes 'myTraces' with an empty Trace object in order to avoid 'null checking'. The real 'Trace' object is set in 'setTraces(Trace trace) {}' method and the code above is not 'problematic'.

Quote:

Is there something else that I should be doing to make incremental
transformations based on previous traces work? Any example code that I
can be directed to look at?

Thanks,

Christian



Below is simple example that shows how 'incremental update' functionality can be used.

Qvto transformation
import emf.tools;

modeltype ecore "strict" uses ecore('http://www.eclipse.org/emf/2002/Ecore');

transformation TestIncremental(in e : ecore, out ecore);

main() {
	e.objects()[EPackage]->map mapPackage();
}

mapping EPackage::mapPackage() : EPackage {
	if (name = null or self.name.startsWith("_")) {
		name := self.name + "_" + this.currentTimeMillis().toString();
	};
	eClassifiers := self.eClassifiers.map mapClassifier(name);
}

mapping EClassifier::mapClassifier(packName : String) : EClass {
	if (name = null or self.name.startsWith("_")) {
		name := self.name + "_" + this.currentTimeMillis().toString();
	}
}


Note that 'currentTimeMillis()' is used here as the simple replacement for randomize generator in order to check 'incremental update' behavior.

Input model (package with two classifiers)
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test" nsURI="http://test/1.0" nsPrefix="test">
  <eClassifiers xsi:type="ecore:EClass" name="_Class"/>
  <eClassifiers xsi:type="ecore:EDataType" name="DataType" instanceClassName="java.lang.String"/>
</ecore:EPackage>


Java code
	@Test
	public void testInremental() {
		URI uri = URI.createPlatformPluginURI("/qvto.incremental/transforms/TestIncremental.qvto", true); //$NON-NLS-1$
		TransformationExecutor executor = new TransformationExecutor(uri);
		
		ExecutionContextImpl context = new ExecutionContextImpl();
		context.getSessionData().setValue(QVTEvaluationOptions.INCREMENTAL_UPDATE_TRACE, Trace.createEmptyTrace());

		BlackboxRegistry blackboxRegistry = TransformationExecutor.BlackboxRegistry.INSTANCE;
		blackboxRegistry.registerModule(EmfToolsLibrary.class, "emf.tools", "tools", new String[] {"http://www.eclipse.org/emf/2002/Ecore"});
		
		URI inModelUri = URI.createPlatformPluginURI("/qvto.incremental/mm/in.ecore", true); //$NON-NLS-1$
		ModelExtent inExtent = new BasicModelExtent(new ResourceSetImpl().getResource(inModelUri, true).getContents());

		String clsName, dtName;
		try {
			ModelExtent outExtent = new BasicModelExtent();
			ExecutionDiagnostic result = executor.execute(context, inExtent, outExtent);
			assertTrue(result.getSeverity() == Diagnostic.OK);
			
			EPackage pack = (EPackage) outExtent.getContents().get(0);
			clsName = pack.getEClassifiers().get(0).getName();
			dtName = pack.getEClassifiers().get(1).getName();
		}
		finally {
			executor.cleanup();
		}

		String clsName2, dtName2;
		try {
			ModelExtent outExtent = new BasicModelExtent();
			ExecutionDiagnostic result = executor.execute(context, inExtent, outExtent);
			assertTrue(result.getSeverity() == Diagnostic.OK);

			EPackage pack = (EPackage) outExtent.getContents().get(0);
			clsName2 = pack.getEClassifiers().get(0).getName();
			dtName2 = pack.getEClassifiers().get(1).getName();
		}
		finally {
			executor.cleanup();
		}
		
		assertEquals(dtName, dtName2);
		assertFalse(clsName.equals(clsName2));
	}


Transformation executor for the second evaluation can certainly be instantiated as the new object. But transformation URI should point to the same Qvto module. And 'Trace' object for the 'incremental update' should be provided manually.

		String clsName2, dtName2;
		try {
			TransformationExecutor executor2 = new TransformationExecutor(uri);
			ExecutionContextImpl context2 = new ExecutionContextImpl();
			context2.getSessionData().setValue(QVTEvaluationOptions.INCREMENTAL_UPDATE_TRACE, context.getSessionData().getValue(QVTEvaluationOptions.INCREMENTAL_UPDATE_TRACE));
			
			ModelExtent outExtent = new BasicModelExtent();
			ExecutionDiagnostic result = executor2.execute(context2, inExtent, outExtent);
			assertTrue(result.getSeverity() == Diagnostic.OK);

			EPackage pack = (EPackage) outExtent.getContents().get(0);
			clsName2 = pack.getEClassifiers().get(0).getName();
			dtName2 = pack.getEClassifiers().get(1).getName();
		}
		finally {
			executor.cleanup();
		}


Regards,
Sergey.
Re: Incremental transformation not working because input traces are ignored [message #1735591 is a reply to message #1735531] Tue, 21 June 2016 11:11 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 171
Registered: July 2009
Senior Member
Hi Christian,

Christian W. Damus wrote on Mon, 20 June 2016 15:51
As it turns out, having prototyped a simple change that satisfies my
use case, I'm not sure that this is a change worth pursuing in QVTo for
my purposes.

I spent some time looking through the existing JUnit tests to see how
to build a regression test for my changes, and of course I saw the
tests that cover the incremental transformation feature implemented in
Mars. And digging deeper to see why those tests pass it became
apparent that there are two quite different ways in which traces are
used by the QVTo TransformationExecutor. These two different ways are
illustrated in the evaluation-visitor's handling of mapping operations:

* a trace found in the executor's current output trace model completely
short-circuits the mapping execution, immediately returning a
found-in-trace result

* a trace found in the IContext trace model supplied by the application
from a previous transformation half short-circuits the mapping
execution. The mapping result is not re-created, instead re-used from
before, but the rest of the mapping execution is still done, including
(AFAICT) executing the mapping body on the pre-existing result, putting
the pre-existing result into the extent, and adding a trace to the
current output trace model so that subsequent evaluations will
short-circuit completely as above

My "fix" for my scenario basically initialized the transaction
executor's output trace (in the evaluation environment) as a copy of
the incoming trace model supplied by the application from the previous
execution. This caused a bunch of test cases to fail because now they
were short-circuiting in the wrong way, such that output extents were
not being populated that should have been. Clearly, that's not good.

So, what this means is that the trace model supplied by the application
can only implement incremental evaluation of mapping rules. It cannot
be queried by a mapping using the invresolve and invresolveIn
operations, which only look at the output trace model, not the input
traces. And I don't want to start fiddling with those operations,
because that would probably break even more stuff.

So, for my purposes, I've found another solution to my original problem
that doesn't require changing how the trace history is used by the
evaluation environment. If I ever find another problem that can't
reasonably be addressed another way, I may have to revisit this
trace-model business and will almost certainly need help from the QVTo
committer team.

Thanks,

Christian


You've absolutely correctly described how traces are used by Qvto executor.

Btw, I'm using the following naming:
- trace from the executor's current output trace model is "execution" trace object
- trace from the IContext trace model supplied by the application is "incremental update" trace object

Generally "incremental update" trace can not be used right in place of "execution" trace for the second and subsequent invocations because this will prevent the mapping's update logic to be performed.

The "incremental update" trace is analyzed only when the 'implicit instantiation' for 'out' objects of mapping is performed.
And also invresolve* family operations does not consider 'incremental update' trace because of imperative nature of Qvto - there's no guarantee that upon subsequent executions the same relationships between input and output models will be established. This means that real relationship is established only by mappings.

I've attached brief description of the logic how the 'incremental update' works.


Regards,
Sergey.
Re: Incremental transformation not working because input traces are ignored [message #1735592 is a reply to message #1735583] Tue, 21 June 2016 11:18 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1165
Registered: July 2009
Location: Canada
Senior Member

Hi, Sergey,

Thanks for the response; it's good to hear from you.

As I indicated (perhaps obliquely) in my other post, I have since
discovered the JUnit tests for the incremental (re-)transformation
scenario that illuminated for me the intention of this API. And my
conclusion from that was that this API's purpose is only to support
repeated execution of the same transformation on the same extents,
which is different from my scenario. I was hoping that in my case I
could make use of the same mechanisms that make the incremental update
work, but it turns out that the mechanisms are different, which is
okay, and also that trying to unify them would not work, which is also
okay.

In my case, I have a sequence of transformations applied to the same
extents that map different subsets of the inputs. I also have an
extension point that contributes additional transformations, especially
for handling of application- or domain-specific concerns such as UML
profiles. One of the needs that these plugged-in transformations have
is to be able to query which source elements generated a particular
target element using the invresolve or invresolveone operation. I had
expected that the trace model supplied to the transformation executor
would feed into these resolve operations as it does into the mapping
execution guard, but it doesn't and I can see that it would be
difficult to make it so.

So, as it turns out, I don't have a bugzilla to raise and I have worked
out a solution that operates more explicitly on the trace model without
trying to execute the transformations as incremental updates.

Cheers,

Christian


On 2016-06-21 10:37:03 +0000, Sergey Boyko said:

> Hello Christian,
>
> Christian W. Damus wrote on Sat, 18 June 2016 19:23
>> Hi,
>>
>> It appears that incremental transformation support was implemented in
>> the Mars release using a new Trace utility class and related IContext.
>> Together, these are supposed to allow a client to inject Traces
>> obtained from a previous transformation execution into a
>> TransformationExecutor for the next transformation, so that the latter
>> can find traceability of mappings from the previous transformation.
>>
>> However, I am unable to get it to work. I create an EvaluationContext
>> and set a Trace object into the session data and then I see that
>> execution of a transformation puts all of its traces into that Trace
>> object for me. So far, so good.
>>
>> Now, when I take this resulting Trace object and set it into the
>> EvaluationContext of the transformation, it is completely ignored, and
>> the output traces are just the traces for mappings evaluated by the
>> second transformation.
>
>
> I'm not quite understand your scenario. Looks like you're trying to use
> 'Trace' object from one evaluation result as the incremental update
> trace for the other evaluation.
>
> Note that each trace record is identified with fully qualified name
> which includes not only mapping name itself but also the name of
> transformation module. So it's impossible to use the trace created for
> one transformation as the input for the different transformation (even
> in case these transformations contain mappings with equal signatures).
>
>
> Quote:
>> The problem seems to be that in the
>> QVTOperationalEvaluationEnv.RootInternal class, the constructor just
>> ignores the incoming Trace object in the IContext:
>>
>> RootInternal(IContext context) {
>> assert context != null;
>> myContext = context;
>> myIsDeferredExecution = false;
>> myTraces = TraceFactory.eINSTANCE.createTrace();
>> }
>>
>> See how 'myTraces' is just created new, instead of being taken from the
>> context.
>
>
> Constructor of 'RootInternal class' quoted above initializes 'myTraces'
> with an empty Trace object in order to avoid 'null checking'. The real
> 'Trace' object is set in 'setTraces(Trace trace) {}' method and the
> code above is not 'problematic'.
>
> Quote:
>> Is there something else that I should be doing to make incremental
>> transformations based on previous traces work? Any example code that I
>> can be directed to look at?
>>
>> Thanks,
>>
>> Christian
>
>
>
> Below is simple example that shows how 'incremental update'
> functionality can be used.
>
> Qvto transformation
>
> import emf.tools;
>
> modeltype ecore "strict" uses ecore('http://www.eclipse.org/emf/2002/Ecore');
>
> transformation TestIncremental(in e : ecore, out ecore);
>
> main() {
> e.objects()[EPackage]->map mapPackage();
> }
>
> mapping EPackage::mapPackage() : EPackage {
> if (name = null or self.name.startsWith("_")) {
> name := self.name + "_" + this.currentTimeMillis().toString();
> };
> eClassifiers := self.eClassifiers.map mapClassifier(name);
> }
>
> mapping EClassifier::mapClassifier(packName : String) : EClass {
> if (name = null or self.name.startsWith("_")) {
> name := self.name + "_" + this.currentTimeMillis().toString();
> }
> }
>
>
> Note that 'currentTimeMillis()' is used here as the simple replacement
> for randomize generator in order to check 'incremental update' behavior.
>
> Input model (package with two classifiers)
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="test"
> nsURI="http://test/1.0" nsPrefix="test">
> <eClassifiers xsi:type="ecore:EClass" name="_Class"/>
> <eClassifiers xsi:type="ecore:EDataType" name="DataType"
> instanceClassName="java.lang.String"/>
> </ecore:EPackage>
>
>
> Java code
>
> @Test
> public void testInremental() {
> URI uri =
> URI.createPlatformPluginURI("/qvto.incremental/transforms/TestIncremental.qvto",
> true); //$NON-NLS-1$
> TransformationExecutor executor = new TransformationExecutor(uri);
>
> ExecutionContextImpl context = new ExecutionContextImpl();
>
> context.getSessionData().setValue(QVTEvaluationOptions.INCREMENTAL_UPDATE_TRACE,
> Trace.createEmptyTrace());
>
> BlackboxRegistry blackboxRegistry =
> TransformationExecutor.BlackboxRegistry.INSTANCE;
> blackboxRegistry.registerModule(EmfToolsLibrary.class, "emf.tools",
> "tools", new String[] {"http://www.eclipse.org/emf/2002/Ecore"});
>
> URI inModelUri =
> URI.createPlatformPluginURI("/qvto.incremental/mm/in.ecore", true);
> //$NON-NLS-1$
> ModelExtent inExtent = new BasicModelExtent(new
> ResourceSetImpl().getResource(inModelUri, true).getContents());
>
> String clsName, dtName;
> try {
> ModelExtent outExtent = new BasicModelExtent();
> ExecutionDiagnostic result = executor.execute(context, inExtent, outExtent);
> assertTrue(result.getSeverity() == Diagnostic.OK);
>
> EPackage pack = (EPackage) outExtent.getContents().get(0);
> clsName = pack.getEClassifiers().get(0).getName();
> dtName = pack.getEClassifiers().get(1).getName();
> }
> finally {
> executor.cleanup();
> }
>
> String clsName2, dtName2;
> try {
> ModelExtent outExtent = new BasicModelExtent();
> ExecutionDiagnostic result = executor.execute(context, inExtent, outExtent);
> assertTrue(result.getSeverity() == Diagnostic.OK);
>
> EPackage pack = (EPackage) outExtent.getContents().get(0);
> clsName2 = pack.getEClassifiers().get(0).getName();
> dtName2 = pack.getEClassifiers().get(1).getName();
> }
> finally {
> executor.cleanup();
> }
>
> assertEquals(dtName, dtName2);
> assertFalse(clsName.equals(clsName2));
> }
>
>
> Transformation executor for the second evaluation can certainly be
> instantiated as the new object. But transformation URI should point to
> the same Qvto module. And 'Trace' object for the 'incremental update'
> should be provided manually.
>
>
> String clsName2, dtName2;
> try {
> TransformationExecutor executor2 = new TransformationExecutor(uri);
> ExecutionContextImpl context2 = new ExecutionContextImpl();
>
> context2.getSessionData().setValue(QVTEvaluationOptions.INCREMENTAL_UPDATE_TRACE,
> context.getSessionData().getValue(QVTEvaluationOptions.INCREMENTAL_UPDATE_TRACE));
>
>
> ModelExtent outExtent = new BasicModelExtent();
> ExecutionDiagnostic result = executor2.execute(context2, inExtent,
> outExtent);
> assertTrue(result.getSeverity() == Diagnostic.OK);
>
> EPackage pack = (EPackage) outExtent.getContents().get(0);
> clsName2 = pack.getEClassifiers().get(0).getName();
> dtName2 = pack.getEClassifiers().get(1).getName();
> }
> finally {
> executor.cleanup();
> }
>
>
> Regards,
> Sergey.
Re: Incremental transformation not working because input traces are ignored [message #1735611 is a reply to message #1735592] Tue, 21 June 2016 12:34 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 171
Registered: July 2009
Senior Member
Hi Christian,

Christian W. Damus wrote on Tue, 21 June 2016 07:18
Hi, Sergey,


In my case, I have a sequence of transformations applied to the same
extents that map different subsets of the inputs. I also have an
extension point that contributes additional transformations, especially
for handling of application- or domain-specific concerns such as UML
profiles. One of the needs that these plugged-in transformations have
is to be able to query which source elements generated a particular
target element using the invresolve or invresolveone operation. I had
expected that the trace model supplied to the transformation executor
would feed into these resolve operations as it does into the mapping
execution guard, but it doesn't and I can see that it would be
difficult to make it so.


Thank you for the detailed description of your case. Indeed 'incremental update' execution as it is realized in Qvto does not suit your requirements.

In order to provide some help for your scenario we can do the following -

For now there's an access to execution context from BlackBox libraries
public class AnnotatedJavaLibrary {

	@Operation (kind=Kind.HELPER, withExecutionContext=true)
	public void logToConsole(IContext context, String param) {
		context.getLog().log(param);
	}
}


Thus there's an access to "incremental update" trace
	org.eclipse.m2m.qvt.oml.util.Trace updateTrace = context.getTrace();


We can implement some helper that will operate on this 'Trace' object and provide resolve/invresolve functionality you need.

Quote:

So, as it turns out, I don't have a bugzilla to raise and I have worked
out a solution that operates more explicitly on the trace model without
trying to execute the transformations as incremental updates.

Cheers,

Christian


Regards,
Sergey.
Re: Incremental transformation not working because input traces are ignored [message #1735617 is a reply to message #1735611] Tue, 21 June 2016 12:46 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1165
Registered: July 2009
Location: Canada
Senior Member

Hi, Sergey,

That's basically exactly what I have done in Papyrus: I've added a
different session-data object in the ExecutionContext that a suite of
black-box queries can access via the IContext.

:-)

I'm not sure that it is a generally useful mechanism, but if you think
it would be, we could consider a contribution. In particular, I use a
different key in the session-data so that the evaluation of mappings
doesn't spend time looking through incremental-update traces that
aren't meant to be used in that way. So, it really is a fairly
application-specific design.

cW


On 2016-06-21 12:34:47 +0000, Sergey Boyko said:

> Hi Christian,
>
> Christian W. Damus wrote on Tue, 21 June 2016 07:18
>> Hi, Sergey,
>>
>>
>> In my case, I have a sequence of transformations applied to the same
>> extents that map different subsets of the inputs. I also have an
>> extension point that contributes additional transformations, especially
>> for handling of application- or domain-specific concerns such as UML
>> profiles. One of the needs that these plugged-in transformations have
>> is to be able to query which source elements generated a particular
>> target element using the invresolve or invresolveone operation. I had
>> expected that the trace model supplied to the transformation executor
>> would feed into these resolve operations as it does into the mapping
>> execution guard, but it doesn't and I can see that it would be
>> difficult to make it so.
>
>
> Thank you for the detailed description of your case. Indeed
> 'incremental update' execution as it is realized in Qvto does not suit
> your requirements.
>
> In order to provide some help for your scenario we can do the following -
>
> For now there's an access to execution context from BlackBox libraries
>
> public class AnnotatedJavaLibrary {
>
> @Operation (kind=Kind.HELPER, withExecutionContext=true)
> public void logToConsole(IContext context, String param) {
> context.getLog().log(param);
> }
> }
>
>
> Thus there's an access to "incremental update" trace
>
> org.eclipse.m2m.qvt.oml.util.Trace updateTrace = context.getTrace();
>
>
> We can implement some helper that will operate on this 'Trace' object
> and provide resolve/invresolve functionality you need.
>
> Quote:
>> So, as it turns out, I don't have a bugzilla to raise and I have worked
>> out a solution that operates more explicitly on the trace model without
>> trying to execute the transformations as incremental updates.
>>
>> Cheers,
>>
>> Christian
>
>
> Regards,
> Sergey.
Re: Incremental transformation not working because input traces are ignored [message #1735618 is a reply to message #1735617] Tue, 21 June 2016 12:47 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1165
Registered: July 2009
Location: Canada
Senior Member

For reference, you can see what I'm doing, here:

https://git.eclipse.org/r/#/c/75597/

cW


On 2016-06-21 12:46:30 +0000, Christian W. Damus said:

> Hi, Sergey,
>
> That's basically exactly what I have done in Papyrus: I've added a
> different session-data object in the ExecutionContext that a suite of
> black-box queries can access via the IContext.
>
> :-)
>
> I'm not sure that it is a generally useful mechanism, but if you think
> it would be, we could consider a contribution. In particular, I use a
> different key in the session-data so that the evaluation of mappings
> doesn't spend time looking through incremental-update traces that
> aren't meant to be used in that way. So, it really is a fairly
> application-specific design.
>
> cW
>
>
> On 2016-06-21 12:34:47 +0000, Sergey Boyko said:
>
>> Hi Christian,
>>
>> Christian W. Damus wrote on Tue, 21 June 2016 07:18
>>> Hi, Sergey,
>>>
>>>
>>> In my case, I have a sequence of transformations applied to the same
>>> extents that map different subsets of the inputs. I also have an
>>> extension point that contributes additional transformations, especially
>>> for handling of application- or domain-specific concerns such as UML
>>> profiles. One of the needs that these plugged-in transformations have
>>> is to be able to query which source elements generated a particular
>>> target element using the invresolve or invresolveone operation. I had
>>> expected that the trace model supplied to the transformation executor
>>> would feed into these resolve operations as it does into the mapping
>>> execution guard, but it doesn't and I can see that it would be
>>> difficult to make it so.
>>
>>
>> Thank you for the detailed description of your case. Indeed
>> 'incremental update' execution as it is realized in Qvto does not suit
>> your requirements.
>>
>> In order to provide some help for your scenario we can do the following -
>>
>> For now there's an access to execution context from BlackBox libraries
>>
>> public class AnnotatedJavaLibrary {
>>
>> @Operation (kind=Kind.HELPER, withExecutionContext=true)
>> public void logToConsole(IContext context, String param) {
>> context.getLog().log(param);
>> }
>> }
>>
>>
>> Thus there's an access to "incremental update" trace
>>
>> org.eclipse.m2m.qvt.oml.util.Trace updateTrace = context.getTrace();
>>
>>
>> We can implement some helper that will operate on this 'Trace' object
>> and provide resolve/invresolve functionality you need.
>>
>> Quote:
>>> So, as it turns out, I don't have a bugzilla to raise and I have worked
>>> out a solution that operates more explicitly on the trace model without
>>> trying to execute the transformations as incremental updates.
>>>
>>> Cheers,
>>>
>>> Christian
>>
>>
>> Regards,
>> Sergey.
Re: Incremental transformation not working because input traces are ignored [message #1735846 is a reply to message #1735618] Thu, 23 June 2016 09:12 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 171
Registered: July 2009
Senior Member
Hi Christian ,

I looked at Gerrit patch. You are perfectly solved the problem by making use of IContext storage.
I doubt that for now there's a need for some general solution.

Regards,
Sergey.


Christian W. Damus wrote on Tue, 21 June 2016 08:47
For reference, you can see what I'm doing, here:

https://git.eclipse.org/r/#/c/75597/

cW


On 2016-06-21 12:46:30 +0000, Christian W. Damus said:

> Hi, Sergey,
>
> That's basically exactly what I have done in Papyrus: I've added a
> different session-data object in the ExecutionContext that a suite of
> black-box queries can access via the IContext.
>
> Smile
>
> I'm not sure that it is a generally useful mechanism, but if you think
> it would be, we could consider a contribution. In particular, I use a
> different key in the session-data so that the evaluation of mappings
> doesn't spend time looking through incremental-update traces that
> aren't meant to be used in that way. So, it really is a fairly
> application-specific design.
>
> cW
>
>

Re: Incremental transformation not working because input traces are ignored [message #1737035 is a reply to message #1735418] Tue, 05 July 2016 08:52 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 57
Registered: April 2011
Member
Christian W. Damus wrote on Sat, 18 June 2016 19:23

It appears that incremental transformation support was implemented in
the Mars release using a new Trace utility class and related IContext.
Together, these are supposed to allow a client to inject Traces
obtained from a previous transformation execution into a
TransformationExecutor for the next transformation, so that the latter
can find traceability of mappings from the previous transformation.


Hi Christian

In Eclipse QVTo, you are currently able to reuse traces from an arbitary previous transformation by making use of transformation composition. The example below demonstrates how to execute a chain of three transformations T1, T2, and T3, sharing a common trace:

transformation Main(in input: ecore, out output : ecore) access T1,T2,T3;

modeltype ecore uses 'http://www.eclipse.org/emf/2002/Ecore';

main() {
       
       var intermediate1 = ecore.createEmptyModel();
       var step1 = new T1(input, intermediate1);
       step1.transform();
       
       var intermediate2 = ecore.createEmptyModel();
       var step2 = new T2(intermediate1, intermediate2);
       step2.transform();
       
       var step3 = new T3(intermediate2, output);
       step2.transform();

       ...
}


This behavior was enabled in the course of bug 392153.

However, to my disappointment, the behavior has been banned explicitly for QVT 1.3 which states that the trace doesn't include trace records for mappings executed "by transformation invocations".

Ed proposed some helpful workarounds for more flexible trace propagation on the QVTo developer mailing list, but they involve language extensions which didn't make it to the specification yet.
Re: Incremental transformation not working because input traces are ignored [message #1737045 is a reply to message #1737035] Tue, 05 July 2016 09:37 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5640
Registered: July 2009
Senior Member
On 05/07/2016 10:52, Christopher Gerking wrote:
> This behavior was enabled in the course of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=392153.
> However, to my disappointment, the behavior has been banned explicitly
> for http://www.omg.org/cgi-bin/doc?formal/16-06-03.pdf which states that
> the trace doesn't include trace records for mappings executed "by
> transformation invocations".

.... since the trace data is for a transformation.

Trace data for invoked transformations should be in the trace data of
the invoked transformation.

I see a strong case for the trace of the invoking transformation having
a trace record that references the invoked trace.

The current underspecified trace model is

1 Tracedata for one transformation contains
N Tracerecord for one mapping invocation

If nested invocations are to be accommodated a proper model needs to be
designed.

For QVTo it is also necessary to answer the question of whether
re-invocation of a transformation with unchanged inputs re-executes.

IMHO multi-transformation execution is a research area that needs
experience input for the QVT spec to address. IIRC the examples you
produced were a workaround for an Eclipse QVTo bug, so I am not aware of
any multi-transformation usage that needs addressing.

Regards

Ed Willink




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: Incremental transformation not working because input traces are ignored [message #1737066 is a reply to message #1737035] Tue, 05 July 2016 12:47 Go to previous message
Christian W. Damus is currently offline Christian W. DamusFriend
Messages: 1165
Registered: July 2009
Location: Canada
Senior Member

Thanks, Christopher,

In my case, the existing framework in Papyrus that is built around
these QVTo transformations allows applications to contribute
"participants" in something more or less like Eclipse's LTK
refactorings. These participants decide for themselves which of their
own QVTo transformations that they wish to execute and when, so it
doesn't really work out to this kind of composition within the QVTo
language. But, this is something I'll want to investigate when I next
revisit this corner of Papyrus.

Cheers!

Christian


On 2016-07-05 08:52:53 +0000, Christopher Gerking said:

> Christian W. Damus wrote on Sat, 18 June 2016 19:23
>> It appears that incremental transformation support was implemented in
>> the Mars release using a new Trace utility class and related IContext.
>> Together, these are supposed to allow a client to inject Traces
>> obtained from a previous transformation execution into a
>> TransformationExecutor for the next transformation, so that the latter
>> can find traceability of mappings from the previous transformation.
>
>
> Hi Christian
>
> In Eclipse QVTo, you are currently able to reuse traces from an
> arbitary previous transformation by making use of transformation
> composition. The example below demonstrates how to execute a chain of
> three transformations T1, T2, and T3, sharing a common trace:
>
>
> transformation Main(in input: ecore, out output : ecore) access T1,T2,T3;
>
> modeltype ecore uses 'http://www.eclipse.org/emf/2002/Ecore';
>
> main() {
> var intermediate1 = ecore.createEmptyModel();
> var step1 = new T1(input, intermediate1);
> step1.transform();
> var intermediate2 = ecore.createEmptyModel();
> var step2 = new T2(intermediate1, intermediate2);
> step2.transform();
> var step3 = new T3(intermediate2, output);
> step2.transform();
>
> ...
> }
>
>
> This behavior was enabled in the course of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=392153.
> However, to my disappointment, the behavior has been banned explicitly
> for http://www.omg.org/cgi-bin/doc?formal/16-06-03.pdf which states
> that the trace doesn't include trace records for mappings executed "by
> transformation invocations".
>
> Ed proposed some helpful workarounds for more flexible trace
> propagation on the QVTo developer mailing list, but they involve
> language extensions which didn't make it to the specification yet.
Previous Topic:Model Abstrction
Next Topic:QVT 1.3
Goto Forum:
  


Current Time: Sat Feb 24 03:50:35 GMT 2018

Powered by FUDForum. Page generated in 0.03121 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software