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
don’t 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
don’t 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
