Find in-line comments
Hi Horacio
The type checking is an area where QVTc doesn't naturally inherit OCL semantics.
In OCL, a variable initialization must be type conformant.
In QVTc, a mapping binding reuses a Variable, but the type check is now a run-time predicate.
[Horacio Hoyos Rodriguez]
So I do have to check at runtime that the binding or variable initialization is of the specific type?
Multiple visits, same Mapping, same bound variables, can occur as a result of rule inheritance, but the flattening of rule inheritance should eliminate it. So there should be no need for any run-time support (I hope).
[Horacio Hoyos Rodriguez]
I see your point, but this might just happen as the effect of having two collection bindings in the mapping call. I know the transformation should try to avoid this, but I dont know if it can be guaranteed, or if we should make it a restriction and then add additional mapping calls to comply.
Regards
Ed Willink
On 31/07/2013 16:51, Horacio Hoyos Rodriguez wrote:
Hi Ed,
After adding more debugging capabilities, I realized in the UMl2RDBMS transformation there is no guard at the mapping level to differentiate Primitive attributes from Complex ones. Thus, invoking the mapping calls:
map classPrimitiveAttributesLM {
c := c;
a <= c.attributes;
fao := c2t;
}
map classComplexAttributesLM {
c := c;
a <= c.attributes;
fao := c2t;
}
Will treat primitive attributes as complex ones during invocation of the second call. The type check at the mapping call level will work for primitives (t:PrimitiveDataType), but for complex attributes the check is at a higher level (a:Attribute) and thus primitive attributes will comply.
The next test in classComplexAttributesLM would be in the variable initializer: t := a.type;, however OCL is not complaining about a class being assigned a PrimitiveDataType
perhaps because they are both Classifiers?
I have to step through the variable visit method and see what is exactly going on.
I have pushed the changes to the TracingDecorator (it now also prints the middle model elements after a mapping bottom pattern is visited to know its state).
---
Other thing that has to be defined is how to deal with multiple visiting of the same element. There was a bug in the mapping call to classPrimitiveAttributesLM in classToTableLM, having an additional binding for p2n. Thus, all the attributes where visited three times (there are three p2n elements at that time) and the middle model ended up with three AttributeToColum elements for each primitive attribute. Possibly keep a list of visited elements and skip
but I dont like that solution as some transformations (in my experience) require multiple visits to the same elements in the source model.
Regards,
Horacio Hoyos Rodríguez
EngD Student
University of York
http://www.york.ac.uk/docs/disclaimer/email.htm
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvtd-dev
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6537 - Release Date: 07/30/13
