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
