Home » Archived » M2M (model-to-model transformation) » [QVTO] Help Transforming data types?
|
| Re: [QVTO] Help Transforming data types? [message #91192 is a reply to message #91129] |
Fri, 03 October 2008 10:59   |
 Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Matt,
This limitation comes from the MDT OCL, as its type system see them as =
non-conformant types.
Though, from the runtime perspective you see them identical.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=3D245619 at MDT OCL.
Also discussed at 'eclipse.modeling.mdt.ocl' newsgroup in "Type =
conformance issues".
However, QVTO might address this issue by adding custom convertion =
operations
into 'emf.tools' library bundled with QVTO, which would be a proper plac=
e =
for solving
non-std QVT but practical model issues.
Regards,
/Radek
On Fri, 03 Oct 2008 05:36:36 +0200, Matthew Watson =
<mattw_watson@yahoo.com> wrote:
> Hi,
>
> I am transforming between models where an attribute in the destination=
=
> is set from an attribute in the source.
>
> The problem is, the types of these attributes, while both BigDecimals =
in =
> the generated Java code, are ecore::EBigDecimal on the source and =
> PositiveDecimal (which also has an instance type name of =
> java.math.BigDecimal) and when I try to assign to one from the other, =
=
> the QVTO editor gives me the error:
>
> The type 'ecore::EBigDecimal' does not conform to the type =
> 'shared::PositiveDecimal' of the property 'numberOfOptions'
>
> I cannot determine how to create an instance of the target type in qvt=
o =
> or intialise it from the EBigInteger.
>
> Can anyone give me some pointers on how to do this?
>
> I'm using 1.0.0.v20080611 of the Operational QVT SDK.
>
> Thanks,
> Matt
>
-- =
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: [QVTO] Help Transforming data types? [message #91814 is a reply to message #91192] |
Thu, 09 October 2008 05:37 |
Matthew Watson
Messages: 4
Registered: July 2009 |
Junior Member |
|
|
Hi Radek,
Thanks for the response.
I'm very new to QVTO...
I was able to get the QVTO editor to accept my code by doing the following:
-----------------
mapping Input::toOutput() : Output {
positiveDecimalField:= self.map getPosDec();
}
mapping Input::getPosDec() : PositiveDecimal;
--------------------
However, when I run it, I get:
org.eclipse.m2m.internal.qvt.oml.evaluator.QvtRuntimeExcepti on: Blackbox
rules are not supported: getPosDec
So I presume I can't just write this conversion in Java and use it as a
Black Box? I notice that your "Model Transformation with Operational QVT"
talk from EclipseCon 2008 mentions black boxes on Page 33, but it appears
this is not implemented?
Also, can you be more specific (or give pointers to info/doco) on the
possible solution you mentioned? I can find a
org.eclipse.m2m.qvt.oml.emf.util library, but no emf.tools library. And
given that, how do I extend/use its capabilities to do this translation?
I am very surprised that data type conversions are not supported out of
the box in QVTO. Surely this is a very common scenario? Our model never
deals with integers/floats, always with BigIntegers/Decimals, so how would
we be expected to create a constant value for a BigInteger in QVTO? Are we
restricted to the base OCL types (and where can I find doco on these
types?)
Our target model is generated from the FpML XSD and so generates a lot of
its own data types like this. Would we have to have special handling every
time we need to translate from our input models datatypes to FpML's?
Thanks,
Matt
Radek Dvorak wrote:
> Hi Matt,
> This limitation comes from the MDT OCL, as its type system see them as
> non-conformant types.
> Though, from the runtime perspective you see them identical.
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619 at MDT OCL.
> Also discussed at 'eclipse.modeling.mdt.ocl' newsgroup in "Type
> conformance issues".
> However, QVTO might address this issue by adding custom convertion
> operations
> into 'emf.tools' library bundled with QVTO, which would be a proper place
> for solving
> non-std QVT but practical model issues.
> Regards,
> /Radek
> On Fri, 03 Oct 2008 05:36:36 +0200, Matthew Watson
> <mattw_watson@yahoo.com> wrote:
>> Hi,
>>
>> I am transforming between models where an attribute in the destination
>> is set from an attribute in the source.
>>
>> The problem is, the types of these attributes, while both BigDecimals in
>> the generated Java code, are ecore::EBigDecimal on the source and
>> PositiveDecimal (which also has an instance type name of
>> java.math.BigDecimal) and when I try to assign to one from the other,
>> the QVTO editor gives me the error:
>>
>> The type 'ecore::EBigDecimal' does not conform to the type
>> 'shared::PositiveDecimal' of the property 'numberOfOptions'
>>
>> I cannot determine how to create an instance of the target type in qvto
>> or intialise it from the EBigInteger.
>>
>> Can anyone give me some pointers on how to do this?
>>
>> I'm using 1.0.0.v20080611 of the Operational QVT SDK.
>>
>> Thanks,
>> Matt
>>
|
|
|
| Re: [QVTO] Help Transforming data types? [message #91897 is a reply to message #91814] |
Thu, 09 October 2008 14:25 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Matt,
We do have a black-box library support. Actually, it's a legacy feature
from the
original contribution, will be superseded by
https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266.
(The 'org.eclipse.m2m.qvt.oml.ocl.emf.libraries' contains such a library
definitions)
I have raised, https://bugs.eclipse.org/bugs/show_bug.cgi?id=250267 , which
disallowed assignment of Real type values to attibutes of BigDecimal
(BigInteger is similar case).
AFAIK, MDT OCL type system maps different kind of numbers (short, long,
Big....) used
in model elements like (EAttribute, EOperation) into Real | Integer.
Any numeric operation result in a value coerced to these types.
I guess, I have seen in MDT OCL bugzilla something mentioned about
optional use of
BigDecimal, etc. in internal calculations.
Better to ask in 'eclipse.modeling.mdt.ocl' newsgroup for details.
However, you will still see an explicit declaration like bellow, as
non-conformant:
var bigInt : ecore::EBigInteger := 10;
But you can do the following, as both types are mapped to Real:
var opagueAsReal : Real := obj.customBig; -- MyBig [java.math.BigDecimal]
obj.bigDecimal := opagueAsReal; -- EBigDecimal [java.math.BigDecimal]
-- or directly
obj.bigDecimal := obj.customBig;
without any loss in precision (allways java.lang.BigDecimal values).
Note, that involving a calculation converts its result into Real (as
java.lang.Double)
obj.bigDecimal := obj.customBig + 10;
After fixing the QVTO bug above, you will be able to assign the lower
precision value
to attributes of Bigxxx types.
Regards,
/Radek
On Thu, 09 Oct 2008 07:37:46 +0200, Matthew Watson
<mattw_watson@yahoo.com> wrote:
> Hi Radek,
>
> Thanks for the response.
>
> I'm very new to QVTO...
>
> I was able to get the QVTO editor to accept my code by doing the
> following:
>
> -----------------
> mapping Input::toOutput() : Output {
> positiveDecimalField:= self.map getPosDec();
> }
>
> mapping Input::getPosDec() : PositiveDecimal;
> --------------------
> However, when I run it, I get:
> org.eclipse.m2m.internal.qvt.oml.evaluator.QvtRuntimeExcepti on: Blackbox
> rules are not supported: getPosDec
>
> So I presume I can't just write this conversion in Java and use it as a
> Black Box? I notice that your "Model Transformation with Operational
> QVT" talk from EclipseCon 2008 mentions black boxes on Page 33, but it
> appears this is not implemented?
>
> Also, can you be more specific (or give pointers to info/doco) on the
> possible solution you mentioned? I can find a
> org.eclipse.m2m.qvt.oml.emf.util library, but no emf.tools library. And
> given that, how do I extend/use its capabilities to do this translation?
>
> I am very surprised that data type conversions are not supported out of
> the box in QVTO. Surely this is a very common scenario? Our model never
> deals with integers/floats, always with BigIntegers/Decimals, so how
> would we be expected to create a constant value for a BigInteger in
> QVTO? Are we restricted to the base OCL types (and where can I find doco
> on these types?)
>
> Our target model is generated from the FpML XSD and so generates a lot
> of its own data types like this. Would we have to have special handling
> every time we need to translate from our input models datatypes to
> FpML's?
>
> Thanks,
> Matt
>
> Radek Dvorak wrote:
>
>> Hi Matt,
>
>> This limitation comes from the MDT OCL, as its type system see them as
>> non-conformant types.
>> Though, from the runtime perspective you see them identical.
>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619 at MDT OCL.
>> Also discussed at 'eclipse.modeling.mdt.ocl' newsgroup in "Type
>> conformance issues".
>
>> However, QVTO might address this issue by adding custom convertion
>> operations
>> into 'emf.tools' library bundled with QVTO, which would be a proper
>> place for solving
>> non-std QVT but practical model issues.
>
>> Regards,
>> /Radek
>
>
>> On Fri, 03 Oct 2008 05:36:36 +0200, Matthew Watson
>> <mattw_watson@yahoo.com> wrote:
>
>>> Hi,
>>>
>>> I am transforming between models where an attribute in the
>>> destination is set from an attribute in the source.
>>>
>>> The problem is, the types of these attributes, while both BigDecimals
>>> in the generated Java code, are ecore::EBigDecimal on the source and
>>> PositiveDecimal (which also has an instance type name of
>>> java.math.BigDecimal) and when I try to assign to one from the other,
>>> the QVTO editor gives me the error:
>>>
>>> The type 'ecore::EBigDecimal' does not conform to the type
>>> 'shared::PositiveDecimal' of the property 'numberOfOptions'
>>>
>>> I cannot determine how to create an instance of the target type in
>>> qvto or intialise it from the EBigInteger.
>>>
>>> Can anyone give me some pointers on how to do this?
>>>
>>> I'm using 1.0.0.v20080611 of the Operational QVT SDK.
>>>
>>> Thanks,
>>> Matt
>>>
>
|
|
|
| Re: [QVTO] Help Transforming data types? [message #93555 is a reply to message #91897] |
Wed, 29 October 2008 01:36 |
Matthew Watson
Messages: 24
Registered: July 2009 |
Junior Member |
|
|
Inline responses:
> We do have a black-box library support. Actually, it's a legacy feature
> from the
> original contribution, will be superseded by
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266.
> (The 'org.eclipse.m2m.qvt.oml.ocl.emf.libraries' contains such a library
> definitions)
So if I get the source for this plugin, I'd be able to figure out how to
do a black-box mapping? What is the syntax in qvto for this? Or is it the
same syntax as below, but I won't get the "Blackbox rules are not
supported" error?
> I have raised, https://bugs.eclipse.org/bugs/show_bug.cgi?id=250267 , which
> disallowed assignment of Real type values to attibutes of BigDecimal
> (BigInteger is similar case).
> AFAIK, MDT OCL type system maps different kind of numbers (short, long,
> Big....) used
> in model elements like (EAttribute, EOperation) into Real | Integer.
> Any numeric operation result in a value coerced to these types.
> I guess, I have seen in MDT OCL bugzilla something mentioned about
> optional use of
> BigDecimal, etc. in internal calculations.
> Better to ask in 'eclipse.modeling.mdt.ocl' newsgroup for details.
> However, you will still see an explicit declaration like bellow, as
> non-conformant:
> var bigInt : ecore::EBigInteger := 10;
> But you can do the following, as both types are mapped to Real:
> var opagueAsReal : Real := obj.customBig; -- MyBig [java.math.BigDecimal]
> obj.bigDecimal := opagueAsReal; -- EBigDecimal [java.math.BigDecimal]
> -- or directly
> obj.bigDecimal := obj.customBig;
The problem I get is the editor does not seem to recognise the var keyword
at all. Do I need a newer version than that included in ganymede?
Thanks,
Matt
> without any loss in precision (allways java.lang.BigDecimal values).
> Note, that involving a calculation converts its result into Real (as
> java.lang.Double)
> obj.bigDecimal := obj.customBig + 10;
> After fixing the QVTO bug above, you will be able to assign the lower
> precision value
> to attributes of Bigxxx types.
> Regards,
> /Radek
> On Thu, 09 Oct 2008 07:37:46 +0200, Matthew Watson
> <mattw_watson@yahoo.com> wrote:
>> Hi Radek,
>>
>> Thanks for the response.
>>
>> I'm very new to QVTO...
>>
>> I was able to get the QVTO editor to accept my code by doing the
>> following:
>>
>> -----------------
>> mapping Input::toOutput() : Output {
>> positiveDecimalField:= self.map getPosDec();
>> }
>>
>> mapping Input::getPosDec() : PositiveDecimal;
>> --------------------
>> However, when I run it, I get:
>> org.eclipse.m2m.internal.qvt.oml.evaluator.QvtRuntimeExcepti on: Blackbox
>> rules are not supported: getPosDec
>>
>> So I presume I can't just write this conversion in Java and use it as a
>> Black Box? I notice that your "Model Transformation with Operational
>> QVT" talk from EclipseCon 2008 mentions black boxes on Page 33, but it
>> appears this is not implemented?
>>
>> Also, can you be more specific (or give pointers to info/doco) on the
>> possible solution you mentioned? I can find a
>> org.eclipse.m2m.qvt.oml.emf.util library, but no emf.tools library. And
>> given that, how do I extend/use its capabilities to do this translation?
>>
>> I am very surprised that data type conversions are not supported out of
>> the box in QVTO. Surely this is a very common scenario? Our model never
>> deals with integers/floats, always with BigIntegers/Decimals, so how
>> would we be expected to create a constant value for a BigInteger in
>> QVTO? Are we restricted to the base OCL types (and where can I find doco
>> on these types?)
>>
>> Our target model is generated from the FpML XSD and so generates a lot
>> of its own data types like this. Would we have to have special handling
>> every time we need to translate from our input models datatypes to
>> FpML's?
>>
>> Thanks,
>> Matt
>>
>> Radek Dvorak wrote:
>>
>>> Hi Matt,
>>
>>> This limitation comes from the MDT OCL, as its type system see them as
>>> non-conformant types.
>>> Though, from the runtime perspective you see them identical.
>>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619 at MDT OCL.
>>> Also discussed at 'eclipse.modeling.mdt.ocl' newsgroup in "Type
>>> conformance issues".
>>
>>> However, QVTO might address this issue by adding custom convertion
>>> operations
>>> into 'emf.tools' library bundled with QVTO, which would be a proper
>>> place for solving
>>> non-std QVT but practical model issues.
>>
>>> Regards,
>>> /Radek
>>
>>
>>> On Fri, 03 Oct 2008 05:36:36 +0200, Matthew Watson
>>> <mattw_watson@yahoo.com> wrote:
>>
>>>> Hi,
>>>>
>>>> I am transforming between models where an attribute in the
>>>> destination is set from an attribute in the source.
>>>>
>>>> The problem is, the types of these attributes, while both BigDecimals
>>>> in the generated Java code, are ecore::EBigDecimal on the source and
>>>> PositiveDecimal (which also has an instance type name of
>>>> java.math.BigDecimal) and when I try to assign to one from the other,
>>>> the QVTO editor gives me the error:
>>>>
>>>> The type 'ecore::EBigDecimal' does not conform to the type
>>>> 'shared::PositiveDecimal' of the property 'numberOfOptions'
>>>>
>>>> I cannot determine how to create an instance of the target type in
>>>> qvto or intialise it from the EBigInteger.
>>>>
>>>> Can anyone give me some pointers on how to do this?
>>>>
>>>> I'm using 1.0.0.v20080611 of the Operational QVT SDK.
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>
|
|
|
| Re: [QVTO] Help Transforming data types? [message #93704 is a reply to message #93555] |
Wed, 29 October 2008 12:42 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Another level of inlined responses bellow ;).
> Inline responses:
>
>> We do have a black-box library support. Actually, it's a legacy
>> feature from the
>> original contribution, will be superseded by
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266.
>> (The 'org.eclipse.m2m.qvt.oml.ocl.emf.libraries' contains such a
>> library definitions)
>
> So if I get the source for this plugin, I'd be able to figure out how to
> do a black-box mapping? What is the syntax in qvto for this? Or is it
> the same syntax as below, but I won't get the "Blackbox rules are not
> supported" error?
A black-box helper | mapping declared in QVT concrete syntax (non
black-box)
results in error, the one you have seen.
Clearly, it should have been better diagnosed at compilation time,
will be fixed by https://bugs.eclipse.org/bugs/show_bug.cgi?id=252570
As for the syntax, you can declare the operation signature only.
Additionaly, it can be marked with the 'black-box' keyword explicitly.
FYI, we have recently introduced a new mechanism to create black-box
libraries
(black-box transformation will follow).
https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266
I'm currently documenting things, if you wish, you can watch
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252520.
After that, it's pretty easy to hook your java code into QVTO and will be
early
accessible in integration build we could make on Thu or Fri.
However, the approach I have mentioned above (for now) address only the
case
of complete module black-boxing.
In the future (hopefully not far ;)), we can support merge of operations in
a black-box module into its corresponding non-blackbox QVT module during
execution.
This would match your initial expectations, I guess.
Anyway, I thought that in your case, a Java library defining helpers that
perform the number conversions would be sufficient, am I wrong?
>
>> I have raised, https://bugs.eclipse.org/bugs/show_bug.cgi?id=250267 ,
>> which
>> disallowed assignment of Real type values to attibutes of BigDecimal
>> (BigInteger is similar case).
>
>> AFAIK, MDT OCL type system maps different kind of numbers (short,
>> long, Big....) used
>> in model elements like (EAttribute, EOperation) into Real | Integer.
>> Any numeric operation result in a value coerced to these types.
>> I guess, I have seen in MDT OCL bugzilla something mentioned about
>> optional use of
>> BigDecimal, etc. in internal calculations.
>> Better to ask in 'eclipse.modeling.mdt.ocl' newsgroup for details.
>
>> However, you will still see an explicit declaration like bellow, as
>> non-conformant:
>> var bigInt : ecore::EBigInteger := 10;
>
>> But you can do the following, as both types are mapped to Real:
>
>> var opagueAsReal : Real := obj.customBig; -- MyBig
>> [java.math.BigDecimal]
>> obj.bigDecimal := opagueAsReal; -- EBigDecimal [java.math.BigDecimal]
>> -- or directly
>> obj.bigDecimal := obj.customBig;
>
> The problem I get is the editor does not seem to recognise the var
> keyword at all. Do I need a newer version than that included in ganymede?
Variable declaration is definitely supported in Ganymede.
I assume, it's just a matter of location where you use it.
Check, you do so in an operation scope.
I suggest, you use the 'Galileo' development stream, as here is where the
new
features come.
Regards,
/Radek
>
> Thanks,
> Matt
>
>
>> without any loss in precision (allways java.lang.BigDecimal values).
>
>
>> Note, that involving a calculation converts its result into Real (as
>> java.lang.Double)
>> obj.bigDecimal := obj.customBig + 10;
>
>> After fixing the QVTO bug above, you will be able to assign the lower
>> precision value
>> to attributes of Bigxxx types.
>
>> Regards,
>> /Radek
>
>
>
>
>> On Thu, 09 Oct 2008 07:37:46 +0200, Matthew Watson
>> <mattw_watson@yahoo.com> wrote:
>
>>> Hi Radek,
>>>
>>> Thanks for the response.
>>>
>>> I'm very new to QVTO...
>>>
>>> I was able to get the QVTO editor to accept my code by doing the
>>> following:
>>>
>>> -----------------
>>> mapping Input::toOutput() : Output {
>>> positiveDecimalField:= self.map getPosDec();
>>> }
>>>
>>> mapping Input::getPosDec() : PositiveDecimal;
>>> --------------------
>>> However, when I run it, I get:
>>> org.eclipse.m2m.internal.qvt.oml.evaluator.QvtRuntimeExcepti on:
>>> Blackbox rules are not supported: getPosDec
>>>
>>> So I presume I can't just write this conversion in Java and use it as
>>> a Black Box? I notice that your "Model Transformation with
>>> Operational QVT" talk from EclipseCon 2008 mentions black boxes on
>>> Page 33, but it appears this is not implemented?
>>>
>>> Also, can you be more specific (or give pointers to info/doco) on the
>>> possible solution you mentioned? I can find a
>>> org.eclipse.m2m.qvt.oml.emf.util library, but no emf.tools library.
>>> And given that, how do I extend/use its capabilities to do this
>>> translation?
>>>
>>> I am very surprised that data type conversions are not supported out
>>> of the box in QVTO. Surely this is a very common scenario? Our model
>>> never deals with integers/floats, always with BigIntegers/Decimals,
>>> so how would we be expected to create a constant value for a
>>> BigInteger in QVTO? Are we restricted to the base OCL types (and
>>> where can I find doco on these types?)
>>>
>>> Our target model is generated from the FpML XSD and so generates a
>>> lot of its own data types like this. Would we have to have special
>>> handling every time we need to translate from our input models
>>> datatypes to FpML's?
>>>
>>> Thanks,
>>> Matt
>>>
>>> Radek Dvorak wrote:
>>>
>>>> Hi Matt,
>>>
>>>> This limitation comes from the MDT OCL, as its type system see them
>>>> as non-conformant types.
>>>> Though, from the runtime perspective you see them identical.
>>>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619 at MDT OCL.
>>>> Also discussed at 'eclipse.modeling.mdt.ocl' newsgroup in "Type
>>>> conformance issues".
>>>
>>>> However, QVTO might address this issue by adding custom convertion
>>>> operations
>>>> into 'emf.tools' library bundled with QVTO, which would be a proper
>>>> place for solving
>>>> non-std QVT but practical model issues.
>>>
>>>> Regards,
>>>> /Radek
>>>
>>>
>>>> On Fri, 03 Oct 2008 05:36:36 +0200, Matthew Watson
>>>> <mattw_watson@yahoo.com> wrote:
>>>
>>>>> Hi,
>>>>>
>>>>> I am transforming between models where an attribute in the
>>>>> destination is set from an attribute in the source.
>>>>>
>>>>> The problem is, the types of these attributes, while both
>>>>> BigDecimals in the generated Java code, are ecore::EBigDecimal on
>>>>> the source and PositiveDecimal (which also has an instance type
>>>>> name of java.math.BigDecimal) and when I try to assign to one from
>>>>> the other, the QVTO editor gives me the error:
>>>>>
>>>>> The type 'ecore::EBigDecimal' does not conform to the type
>>>>> 'shared::PositiveDecimal' of the property 'numberOfOptions'
>>>>>
>>>>> I cannot determine how to create an instance of the target type in
>>>>> qvto or intialise it from the EBigInteger.
>>>>>
>>>>> Can anyone give me some pointers on how to do this?
>>>>>
>>>>> I'm using 1.0.0.v20080611 of the Operational QVT SDK.
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>>
>>>
>
|
|
|
| Re: [QVTO] Help Transforming data types? [message #93984 is a reply to message #93704] |
Thu, 30 October 2008 06:52 |
Matthew Watson
Messages: 24
Registered: July 2009 |
Junior Member |
|
|
Hi Radek,
I got the data type transform to work using oclAsType (which stops working
in 2.0.0M2, but direct assignment starts working!).
We are evaluating QVTO and for other reasons wanted to use black box
support.
We currently have a java based transformation that looks for similarly
named classes in the input and output model and automatically transforms
siimilarly named features in them. It breaks out into custom transforms
(written in our proprietary java based transform engine) only where we
need them.
We want to try to do the same thing in QVT - we have an input and output
model that are very similar (FPML and a refactored version of it) where we
refactor to produce better modelling for what we need and to support extra
features, but still need to support input and output in standard fpml (in
multiple versions!).
To write this as a full qvto transform would be a nightmare, as there are
1000+ classes and we'd have to maintain them for multiple versions of the
fpml spec.
Can you suggest some way we could do this. In our proprietary engine, we
declaratively say we want to transform a field to another field in the
target model and it looks for matching transforms between those types (we
don't explicitly specify inherits in transforms, it goes up the
inheritance hierarchy and calls matching abstract type transforms
automatically. If it fails to find a transform, we query a list of
defaults to see if they can handle the transform - one of these knows how
to map class names from the input to output models and maps the fields on
a similar name pattern. It works well.
How could we do something similar in QVTO? Is it possible?
Thanks
Matt
Radek Dvorak wrote:
> Another level of inlined responses bellow ;).
>> Inline responses:
>>
>>> We do have a black-box library support. Actually, it's a legacy
>>> feature from the
>>> original contribution, will be superseded by
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266.
>>> (The 'org.eclipse.m2m.qvt.oml.ocl.emf.libraries' contains such a
>>> library definitions)
>>
>> So if I get the source for this plugin, I'd be able to figure out how to
>> do a black-box mapping? What is the syntax in qvto for this? Or is it
>> the same syntax as below, but I won't get the "Blackbox rules are not
>> supported" error?
> A black-box helper | mapping declared in QVT concrete syntax (non
> black-box)
> results in error, the one you have seen.
> Clearly, it should have been better diagnosed at compilation time,
> will be fixed by https://bugs.eclipse.org/bugs/show_bug.cgi?id=252570
> As for the syntax, you can declare the operation signature only.
> Additionaly, it can be marked with the 'black-box' keyword explicitly.
> FYI, we have recently introduced a new mechanism to create black-box
> libraries
> (black-box transformation will follow).
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266
> I'm currently documenting things, if you wish, you can watch
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252520.
> After that, it's pretty easy to hook your java code into QVTO and will be
> early
> accessible in integration build we could make on Thu or Fri.
> However, the approach I have mentioned above (for now) address only the
> case
> of complete module black-boxing.
> In the future (hopefully not far ;)), we can support merge of operations in
> a black-box module into its corresponding non-blackbox QVT module during
> execution.
> This would match your initial expectations, I guess.
> Anyway, I thought that in your case, a Java library defining helpers that
> perform the number conversions would be sufficient, am I wrong?
>>
>>> I have raised, https://bugs.eclipse.org/bugs/show_bug.cgi?id=250267 ,
>>> which
>>> disallowed assignment of Real type values to attibutes of BigDecimal
>>> (BigInteger is similar case).
>>
>>> AFAIK, MDT OCL type system maps different kind of numbers (short,
>>> long, Big....) used
>>> in model elements like (EAttribute, EOperation) into Real | Integer.
>>> Any numeric operation result in a value coerced to these types.
>>> I guess, I have seen in MDT OCL bugzilla something mentioned about
>>> optional use of
>>> BigDecimal, etc. in internal calculations.
>>> Better to ask in 'eclipse.modeling.mdt.ocl' newsgroup for details.
>>
>>> However, you will still see an explicit declaration like bellow, as
>>> non-conformant:
>>> var bigInt : ecore::EBigInteger := 10;
>>
>>> But you can do the following, as both types are mapped to Real:
>>
>>> var opagueAsReal : Real := obj.customBig; -- MyBig
>>> [java.math.BigDecimal]
>>> obj.bigDecimal := opagueAsReal; -- EBigDecimal [java.math.BigDecimal]
>>> -- or directly
>>> obj.bigDecimal := obj.customBig;
>>
>> The problem I get is the editor does not seem to recognise the var
>> keyword at all. Do I need a newer version than that included in ganymede?
> Variable declaration is definitely supported in Ganymede.
> I assume, it's just a matter of location where you use it.
> Check, you do so in an operation scope.
> I suggest, you use the 'Galileo' development stream, as here is where the
> new
> features come.
> Regards,
> /Radek
>>
>> Thanks,
>> Matt
>>
>>
>>> without any loss in precision (allways java.lang.BigDecimal values).
>>
>>
>>> Note, that involving a calculation converts its result into Real (as
>>> java.lang.Double)
>>> obj.bigDecimal := obj.customBig + 10;
>>
>>> After fixing the QVTO bug above, you will be able to assign the lower
>>> precision value
>>> to attributes of Bigxxx types.
>>
>>> Regards,
>>> /Radek
>>
>>
>>
>>
>>> On Thu, 09 Oct 2008 07:37:46 +0200, Matthew Watson
>>> <mattw_watson@yahoo.com> wrote:
>>
>>>> Hi Radek,
>>>>
>>>> Thanks for the response.
>>>>
>>>> I'm very new to QVTO...
>>>>
>>>> I was able to get the QVTO editor to accept my code by doing the
>>>> following:
>>>>
>>>> -----------------
>>>> mapping Input::toOutput() : Output {
>>>> positiveDecimalField:= self.map getPosDec();
>>>> }
>>>>
>>>> mapping Input::getPosDec() : PositiveDecimal;
>>>> --------------------
>>>> However, when I run it, I get:
>>>> org.eclipse.m2m.internal.qvt.oml.evaluator.QvtRuntimeExcepti on:
>>>> Blackbox rules are not supported: getPosDec
>>>>
>>>> So I presume I can't just write this conversion in Java and use it as
>>>> a Black Box? I notice that your "Model Transformation with
>>>> Operational QVT" talk from EclipseCon 2008 mentions black boxes on
>>>> Page 33, but it appears this is not implemented?
>>>>
>>>> Also, can you be more specific (or give pointers to info/doco) on the
>>>> possible solution you mentioned? I can find a
>>>> org.eclipse.m2m.qvt.oml.emf.util library, but no emf.tools library.
>>>> And given that, how do I extend/use its capabilities to do this
>>>> translation?
>>>>
>>>> I am very surprised that data type conversions are not supported out
>>>> of the box in QVTO. Surely this is a very common scenario? Our model
>>>> never deals with integers/floats, always with BigIntegers/Decimals,
>>>> so how would we be expected to create a constant value for a
>>>> BigInteger in QVTO? Are we restricted to the base OCL types (and
>>>> where can I find doco on these types?)
>>>>
>>>> Our target model is generated from the FpML XSD and so generates a
>>>> lot of its own data types like this. Would we have to have special
>>>> handling every time we need to translate from our input models
>>>> datatypes to FpML's?
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>>> Radek Dvorak wrote:
>>>>
>>>>> Hi Matt,
>>>>
>>>>> This limitation comes from the MDT OCL, as its type system see them
>>>>> as non-conformant types.
>>>>> Though, from the runtime perspective you see them identical.
>>>>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619 at MDT OCL.
>>>>> Also discussed at 'eclipse.modeling.mdt.ocl' newsgroup in "Type
>>>>> conformance issues".
>>>>
>>>>> However, QVTO might address this issue by adding custom convertion
>>>>> operations
>>>>> into 'emf.tools' library bundled with QVTO, which would be a proper
>>>>> place for solving
>>>>> non-std QVT but practical model issues.
>>>>
>>>>> Regards,
>>>>> /Radek
>>>>
>>>>
>>>>> On Fri, 03 Oct 2008 05:36:36 +0200, Matthew Watson
>>>>> <mattw_watson@yahoo.com> wrote:
>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am transforming between models where an attribute in the
>>>>>> destination is set from an attribute in the source.
>>>>>>
>>>>>> The problem is, the types of these attributes, while both
>>>>>> BigDecimals in the generated Java code, are ecore::EBigDecimal on
>>>>>> the source and PositiveDecimal (which also has an instance type
>>>>>> name of java.math.BigDecimal) and when I try to assign to one from
>>>>>> the other, the QVTO editor gives me the error:
>>>>>>
>>>>>> The type 'ecore::EBigDecimal' does not conform to the type
>>>>>> 'shared::PositiveDecimal' of the property 'numberOfOptions'
>>>>>>
>>>>>> I cannot determine how to create an instance of the target type in
>>>>>> qvto or intialise it from the EBigInteger.
>>>>>>
>>>>>> Can anyone give me some pointers on how to do this?
>>>>>>
>>>>>> I'm using 1.0.0.v20080611 of the Operational QVT SDK.
>>>>>>
>>>>>> Thanks,
>>>>>> Matt
>>>>>>
>>>>
>>
|
|
|
| Re: [QVTO] Help Transforming data types? [message #94694 is a reply to message #93984] |
Fri, 07 November 2008 09:33 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Matt,
Sorry for the delay, I have mistakenly overlooked this message.
As for your usecase, in principal you could do a similar thing in QVTo.
If I got you right, you want to reuse the same transformation for
structurally
similar metamodels (see 'effective' conformance kind, 8.1.2 Model types).
Typically, it would require to separate the incompatibilities
in specialized transformations that would extend the common one.
Your custom java transformations could be wrapped as blackbox transfs
and instantiated and executed explicitly from the main transformation
(see 8.1.11 Composing transformations)
Not sure I fully understand the case of the hierarchy traversal
you need but something like implicit 'inherits' for all mappings
that fits to a source object type hierarchy is not available.
QVTo status:
- 'effective' conformance kind is not implemented yet in QVTo.
We are based on MDT OCL, which requires the 'strict' kind by design.
However, it could be emulated by a re-compile on the fly for the given
metamodel used in runtime. It would just require an additional setting
for launching.
- black-box transformations may come early in M4 as the infrastructure is
ready
from the black-box libs support already.
- import by 'extend' will be implemented in M4 too.
Regards,
/Radek
On Thu, 30 Oct 2008 07:52:57 +0100, Matthew Watson
<matthew-j.watson@db.com> wrote:
> Hi Radek,
>
> I got the data type transform to work using oclAsType (which stops
> working in 2.0.0M2, but direct assignment starts working!).
>
> We are evaluating QVTO and for other reasons wanted to use black box
> support.
>
> We currently have a java based transformation that looks for similarly
> named classes in the input and output model and automatically transforms
> siimilarly named features in them. It breaks out into custom transforms
> (written in our proprietary java based transform engine) only where we
> need them.
>
> We want to try to do the same thing in QVT - we have an input and output
> model that are very similar (FPML and a refactored version of it) where
> we refactor to produce better modelling for what we need and to support
> extra features, but still need to support input and output in standard
> fpml (in multiple versions!).
>
> To write this as a full qvto transform would be a nightmare, as there
> are 1000+ classes and we'd have to maintain them for multiple versions
> of the fpml spec.
>
> Can you suggest some way we could do this. In our proprietary engine, we
> declaratively say we want to transform a field to another field in the
> target model and it looks for matching transforms between those types
> (we don't explicitly specify inherits in transforms, it goes up the
> inheritance hierarchy and calls matching abstract type transforms
> automatically. If it fails to find a transform, we query a list of
> defaults to see if they can handle the transform - one of these knows
> how to map class names from the input to output models and maps the
> fields on a similar name pattern. It works well.
>
> How could we do something similar in QVTO? Is it possible?
>
> Thanks
> Matt
>
>
> Radek Dvorak wrote:
>
>> Another level of inlined responses bellow ;).
>
>>> Inline responses:
>>>
>>>> We do have a black-box library support. Actually, it's a legacy
>>>> feature from the
>>>> original contribution, will be superseded by
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266.
>>>> (The 'org.eclipse.m2m.qvt.oml.ocl.emf.libraries' contains such a
>>>> library definitions)
>>>
>>> So if I get the source for this plugin, I'd be able to figure out how
>>> to do a black-box mapping? What is the syntax in qvto for this? Or is
>>> it the same syntax as below, but I won't get the "Blackbox rules are
>>> not supported" error?
>
>> A black-box helper | mapping declared in QVT concrete syntax (non
>> black-box)
>> results in error, the one you have seen.
>> Clearly, it should have been better diagnosed at compilation time,
>> will be fixed by https://bugs.eclipse.org/bugs/show_bug.cgi?id=252570
>
>> As for the syntax, you can declare the operation signature only.
>> Additionaly, it can be marked with the 'black-box' keyword explicitly.
>
>> FYI, we have recently introduced a new mechanism to create black-box
>> libraries
>> (black-box transformation will follow).
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=250266
>> I'm currently documenting things, if you wish, you can watch
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=252520.
>> After that, it's pretty easy to hook your java code into QVTO and will
>> be early
>> accessible in integration build we could make on Thu or Fri.
>
>> However, the approach I have mentioned above (for now) address only
>> the case
>> of complete module black-boxing.
>> In the future (hopefully not far ;)), we can support merge of
>> operations in
>> a black-box module into its corresponding non-blackbox QVT module
>> during execution.
>> This would match your initial expectations, I guess.
>
>> Anyway, I thought that in your case, a Java library defining helpers
>> that
>> perform the number conversions would be sufficient, am I wrong?
>
>>>
>>>> I have raised, https://bugs.eclipse.org/bugs/show_bug.cgi?id=250267
>>>> , which
>>>> disallowed assignment of Real type values to attibutes of BigDecimal
>>>> (BigInteger is similar case).
>>>
>>>> AFAIK, MDT OCL type system maps different kind of numbers (short,
>>>> long, Big....) used
>>>> in model elements like (EAttribute, EOperation) into Real | Integer.
>>>> Any numeric operation result in a value coerced to these types.
>>>> I guess, I have seen in MDT OCL bugzilla something mentioned about
>>>> optional use of
>>>> BigDecimal, etc. in internal calculations.
>>>> Better to ask in 'eclipse.modeling.mdt.ocl' newsgroup for details.
>>>
>>>> However, you will still see an explicit declaration like bellow, as
>>>> non-conformant:
>>>> var bigInt : ecore::EBigInteger := 10;
>>>
>>>> But you can do the following, as both types are mapped to Real:
>>>
>>>> var opagueAsReal : Real := obj.customBig; -- MyBig
>>>> [java.math.BigDecimal]
>>>> obj.bigDecimal := opagueAsReal; -- EBigDecimal
>>>> [java.math.BigDecimal]
>>>> -- or directly
>>>> obj.bigDecimal := obj.customBig;
>>>
>>> The problem I get is the editor does not seem to recognise the var
>>> keyword at all. Do I need a newer version than that included in
>>> ganymede?
>
>> Variable declaration is definitely supported in Ganymede.
>> I assume, it's just a matter of location where you use it.
>> Check, you do so in an operation scope.
>
>> I suggest, you use the 'Galileo' development stream, as here is where
>> the new
>> features come.
>
>> Regards,
>> /Radek
>
>>>
>>> Thanks,
>>> Matt
>>>
>>>
>>>> without any loss in precision (allways java.lang.BigDecimal values).
>>>
>>>
>>>> Note, that involving a calculation converts its result into Real
>>>> (as java.lang.Double)
>>>> obj.bigDecimal := obj.customBig + 10;
>>>
>>>> After fixing the QVTO bug above, you will be able to assign the
>>>> lower precision value
>>>> to attributes of Bigxxx types.
>>>
>>>> Regards,
>>>> /Radek
>>>
>>>
>>>
>>>
>>>> On Thu, 09 Oct 2008 07:37:46 +0200, Matthew Watson
>>>> <mattw_watson@yahoo.com> wrote:
>>>
>>>>> Hi Radek,
>>>>>
>>>>> Thanks for the response.
>>>>>
>>>>> I'm very new to QVTO...
>>>>>
>>>>> I was able to get the QVTO editor to accept my code by doing the
>>>>> following:
>>>>>
>>>>> -----------------
>>>>> mapping Input::toOutput() : Output {
>>>>> positiveDecimalField:= self.map getPosDec();
>>>>> }
>>>>>
>>>>> mapping Input::getPosDec() : PositiveDecimal;
>>>>> --------------------
>>>>> However, when I run it, I get:
>>>>> org.eclipse.m2m.internal.qvt.oml.evaluator.QvtRuntimeExcepti on:
>>>>> Blackbox rules are not supported: getPosDec
>>>>>
>>>>> So I presume I can't just write this conversion in Java and use it
>>>>> as a Black Box? I notice that your "Model Transformation with
>>>>> Operational QVT" talk from EclipseCon 2008 mentions black boxes on
>>>>> Page 33, but it appears this is not implemented?
>>>>>
>>>>> Also, can you be more specific (or give pointers to info/doco) on
>>>>> the possible solution you mentioned? I can find a
>>>>> org.eclipse.m2m.qvt.oml.emf.util library, but no emf.tools library.
>>>>> And given that, how do I extend/use its capabilities to do this
>>>>> translation?
>>>>>
>>>>> I am very surprised that data type conversions are not supported
>>>>> out of the box in QVTO. Surely this is a very common scenario? Our
>>>>> model never deals with integers/floats, always with
>>>>> BigIntegers/Decimals, so how would we be expected to create a
>>>>> constant value for a BigInteger in QVTO? Are we restricted to the
>>>>> base OCL types (and where can I find doco on these types?)
>>>>>
>>>>> Our target model is generated from the FpML XSD and so generates a
>>>>> lot of its own data types like this. Would we have to have special
>>>>> handling every time we need to translate from our input models
>>>>> datatypes to FpML's?
>>>>>
>>>>> Thanks,
>>>>> Matt
>>>>>
>>>>> Radek Dvorak wrote:
>>>>>
>>>>>> Hi Matt,
>>>>>
>>>>>> This limitation comes from the MDT OCL, as its type system see
>>>>>> them as non-conformant types.
>>>>>> Though, from the runtime perspective you see them identical.
>>>>>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=245619 at MDT OCL.
>>>>>> Also discussed at 'eclipse.modeling.mdt.ocl' newsgroup in "Type
>>>>>> conformance issues".
>>>>>
>>>>>> However, QVTO might address this issue by adding custom
>>>>>> convertion operations
>>>>>> into 'emf.tools' library bundled with QVTO, which would be a
>>>>>> proper place for solving
>>>>>> non-std QVT but practical model issues.
>>>>>
>>>>>> Regards,
>>>>>> /Radek
>>>>>
>>>>>
>>>>>> On Fri, 03 Oct 2008 05:36:36 +0200, Matthew Watson
>>>>>> <mattw_watson@yahoo.com> wrote:
>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am transforming between models where an attribute in the
>>>>>>> destination is set from an attribute in the source.
>>>>>>>
>>>>>>> The problem is, the types of these attributes, while both
>>>>>>> BigDecimals in the generated Java code, are ecore::EBigDecimal
>>>>>>> on the source and PositiveDecimal (which also has an instance
>>>>>>> type name of java.math.BigDecimal) and when I try to assign to
>>>>>>> one from the other, the QVTO editor gives me the error:
>>>>>>>
>>>>>>> The type 'ecore::EBigDecimal' does not conform to the type
>>>>>>> 'shared::PositiveDecimal' of the property 'numberOfOptions'
>>>>>>>
>>>>>>> I cannot determine how to create an instance of the target type
>>>>>>> in qvto or intialise it from the EBigInteger.
>>>>>>>
>>>>>>> Can anyone give me some pointers on how to do this?
>>>>>>>
>>>>>>> I'm using 1.0.0.v20080611 of the Operational QVT SDK.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Matt
>>>>>>>
>>>>>
>>>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 10:23:36 GMT 2024
Powered by FUDForum. Page generated in 0.04088 seconds |
] 
Search
Help
Register
Login
Home
