Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvtd-dev] ClassToRDBMSSchedule.qvti review

Hi

I don't understand the error; looks like a bug. I'll investigate.

I've just been checking unnavigable opposites before you try them. An OCL fix is about to be puished to master. I might improve LazyModelManager so that it can be primed with usage requirements.

    Regards

        Ed

On 23/04/2013 16:28, Horacio Hoyos Rodriguez wrote:
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
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/qvtd-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3272 / Virus Database: 3162/6266 - Release Date: 04/22/13






Back to the top