[qvtd-dev] [Dev] QVTi UML2RDBMS faults

[Horacio Hoyos Rodriguez <hhr502@xxxxxxxxxx>]

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