Re: [qvtd-dev] ClassToRDBMSSchedule.qvti review

[Horacio Hoyos Rodriguez <hhr502@xxxxxxxxxx>]

Hi Ed,

I pushed an attempt at completing UML2RDBMS.qvti with the suggested
approach.

If associationToForeignKeyLM was complicated.... I think
associationToForeignKeyMR seems impossible to call with the current
approach.

Also in the attributeColumnsMR the ct variable, which is a string, has no
references nor is referenced in any way. An option is to replace ct by
p2n.typeName in the Mapping.

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