Re: [qvtd-dev] ClassToRDBMSSchedule.qvti review

[Horacio Hoyos Rodriguez <hhr502@xxxxxxxxxx>]

Hi Ed,

I pushed another version of the UML2RDBMS.qvti manual transformation. I
think I sorted some of the complicated bindings. I added an additional
associationToForeignKeyMR mapping. However, the editor shows an error and
I don't understand why. Any clues?

Regards,

Horacio Hoyos Rodríguez
EngD Student
University of York

http://www.york.ac.uk/docs/disclaimer/email.htm


-----Original Message-----
From: qvtd-dev-bounces@xxxxxxxxxxx [mailto:qvtd-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ed Willink
Sent: 22 April 2013 13:45
To: QVTD developers mailing list
Subject: Re: [qvtd-dev] ClassToRDBMSSchedule.qvti review

HI

You are using a very odd mail tool; your comments are hard to distinguish.

Hopefully mine are more distinct.

     Regards

         Ed


On 22/04/2013 12:38, Horacio Hoyos Rodriguez wrote:
> [Horacio Hoyos Rodriguez]
> This will mean analysing the mapping guard predicates to change their
> direction and to make the binding change them to assignments. On a
> mapping
>
> call perspective it means that not all variables need to be bind in
> the mapping call (optional parameters?). My initial proposal is not
> optimal but for the moment I think it is more straight forward to
> compute. Your proposal is more optimal but requires more intelligence
> on the QVTc to QVTi translation. I think we should start with a simple
> and not optimal QVTc to QVTi translation which we can easily program
> into Epsilon (and then QVT) and once that is working see how we can
> optimize it. The syntax error can be fixed by allowing mapping call
> variables to be used in the oclexpressions if they have been defined
previously.
But the QVTc to QVTi does not yet exist, we are still designing
it/manually prototyping its output..

The QVTi executor does and we're trying to get that right.

Introducing a new visibility to support a very inefficient
mis-inplementation cannot be right.
> Clearly the underlying mapping call implementation should have a
> recipient
>
> type filter so that it is sufficient to write
>
>       map associationToForeignKeyLM {
>           p := p;
>           a <= p.elements;
>           p2s := p2s;
>       }
>
> [Horacio Hoyos Rodriguez]
> I was thinking about this too. The GuardPatternVisitor will need
> modification to test if the binded value of the variable is of the
> precise
>
> type. Should the match be exact or will super types be accepted as
> valid matches?
In OO tools, types should almost always be compared with support for
inheritance.

Type.conformsTo(Type) is probably what you need.
> ----------------------------------------------------------------------
> ----
>
> ------
>
> The queries need implementation.
> [Horacio Hoyos Rodriguez]
> How do I pass the queries to the environment? Do I need to visit them
> so OCL knows to what type to associate the query?
> On a side note on this, the getAllForwards query in the QVT
> specification refers to the forward attribute of the Class class. I
> don't have this reference in my SimpleUML metamodel, so will you agree
> this is the opposite of the source reference in the Association class?
>
> You might postpone this for now by inlining them with the aid of the
> closure iteration.
In many respects the correct implementation of a Query is the same as a
Mapping (without loops).
You create a new nested environment and bind all the query parameters to
the invoking arguments.

     Regards

         Ed

_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev