Re: [qvtd-dev] First QVTimperative.ocl results

[Horacio Hoyos Rodriguez <hhr502@xxxxxxxxxx>]

Hi Ed,

In the ClassToRDBMSSchedule.qvti:

integerToNumberLM, booleanToBooleanLM and stringToVarcharMR you removed
the creation of the sql:String, later in rule attributeColumnsMR there
would be no strings created when invoking the mapping from ClassToTable. I
realized there is no binding expression in the call. This two things have
to be checked in the original QVTc transformation and see what is
happening during the transformation.

I moved the assignments to the bottom pattern because they won't affect
the outcome of the guard validation, atm the assignment visitor does not
do any testing to see if the assignment could be done or is valid (check
semantics);
At some point I remember this as being necessary according to  the vesting
order of the mapping's patterns but can no longer find the reason I moved
them.

I see u commented some assignments and reverted some of the variable
names. I will take a closer look at this changes and why (presumably) they
report errors.

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: 16 July 2013 19:55
To: QVTD developers mailing list
Subject: [qvtd-dev] First QVTimperative.ocl results

Hi Horacio

Attached are my first stab at QVTimperative.ocl and a
ClassToRDBMSSchedule.qvti that has no validation errors.

These will be pushed to master once I've fixed a couple of OCL tests that
no longer pass after fixing some problems with loading QVTimperative.ocl.

The WFRs revealed one bad bug in the AST preparation: the
'VariableAssignment's in guard patterns were being thrown away. They are
now folded into the initializer of the variable.

Some of your guard pattern variables where assigned in the bottom rather
than guard pattern.

Some bindings were inaccurate. I've corrected them to make the errors go
away. That doesn't mean that they are semantically sensible.

     Regards

         Ed