In the real usage, the 'secondary' extents are not defined at design time. It is therefore not possible to add them as parameters of the transformation.
Eclipse QVTo went through a rather 'stable' period. But it's moving
again now. There were some significant fixes in Kepler. It's worth
seeing whether you can upgrade even if you must stay with an Indigo
platform.
Regards
Ed Willink
On 20/09/2013 16:58, Vlad Gheorghe wrote:
> Hello,
>
> I use QVTo from Indigo SR2 (v3.1.0).
>
> I have an transformation with one in/out parameter.
>
> At execution time, the resource passed as the parameter contains a
> model which has cross-references to another resource ('secondary
> extent').
>
> I was not able to create new objects and save them into the secondary
> extent.
>
> Please see two attached test cases.
>
> In the real usage, the 'secondary' extents are not defined at design
> time. It is therefore not possible to add them as parameters of the
> transformation.
>
> Any ideas or suggestions would be great.
>
> Cheers
> Vlad
>
8.2.1.5. ModelParameter
Pre-defined operations defined on types can be used to inspect the objects that are part of the model at any time during
the transformation. More precisely there is a MOF extent corresponding to each parameter. Any object creation occurs in
an extent associated with a model parameter.
8.2.1.6 ModelType
Relationship between MOF extents and model parameters
When a model element is created by a transformation it is necessary to know in what model the model element is to be
created. In particular, this makes it possible to use the inspection operations on model parameters like objects() and
objectsOfType() to retrieve an object previously created. In MOF there is a notion of Extent that is simply defined
as a container for Objects. Here we are correlating the notion of model (represented by model parameters in a
transformation definition) with the notion of MOF extent stating that for each model parameter there is a MOF extent.
8.3.5.4 removeElement
Model::removeElement (Element): Void
Removes an object of the model extent. All links that the object have with other objects in the extent are deleted.
8.3.4 Operations on elements
All MOF reflective operations are available, in particular the Element::container() operation that is very useful to inspect
a model.
I suspect you need to raise a Bugzilla; there is some chance it might
even get fixed these days.
Regards
Ed Willink
On 20/09/2013 20:57, Vlad Gheorghe wrote:
> From http://www.omg.org/spec/QVT/1.1/PDF/ :
>
> 8.2.1.5. ModelParameter
> Pre-defined operations defined on types can be used to inspect the
> objects that are part of the model at any time during
> the transformation. More precisely there is a MOF extent corresponding
> to each parameter. Any object creation occurs in
> an extent associated with a model parameter.
>
> 8.2.1.6 ModelType
>
> Relationship between MOF extents and model parameters
> When a model element is created by a transformation it is necessary to
> know in what model the model element is to be
> created. In particular, this makes it possible to use the inspection
> operations on model parameters like objects() and
> objectsOfType() to retrieve an object previously created. In MOF there
> is a notion of Extent that is simply defined
> as a container for Objects. Here we are correlating the notion of
> model (represented by model parameters in a
> transformation definition) with the notion of MOF extent stating that
> for each model parameter there is a MOF extent.
>
> 8.3.5.4 removeElement
> Model::removeElement (Element): Void
> Removes an object of the model extent. All links that the object have
> with other objects in the extent are deleted.
>
> 8.3.4 Operations on elements
> All MOF reflective operations are available, in particular the
> Element::container() operation that is very useful to inspect
> a model.
>