Eclipse Community Forums: EMF » Loading / deserializing non-transient derived features

Home » Modeling » EMF » Loading / deserializing non-transient derived features(Can non-transient derived features be deserialized without leading to an IllegalValueException?)

Show: Today's Messages :: Show Polls :: Message Navigator

Loading / deserializing non-transient derived features [message #1832923]

Tue, 29 September 2020 13:55

Stefan John

Messages: 17
Registered: March 2018

Junior Member

Hi,

I recently added a non-transient derived attribute to one of our metamodels via OCLinEcore.

I tend to often use the Sample Reflective Ecore Model Editor to analyse corresponding instance models. E.g. to create and look at models used for unit testing. As long as those instances are managed in the Sample Reflective Ecore Model Editor this works well as the editor seems to ignore the transient setting and just does not serialize a value for the derived attribute (with exceptions I need to further analyse before probably raising a bug report). Actually, I wonder what the expected behavior of the editor should be. Ignoring the transient setting to keep instances viewable or persisting derived attribute values rendering the instance not loadable?

Anyway, serializing such instance models programatically (Resource.save()) to xmi, the derived attribute is persisted with its current value. Using the XMIResourceFactory to load instances with peristed non-transient derived attributes, however, raises an llegalValueException.

I wonder what the options are to relax the loading process and still load such an instance programatically (ignoring the serialized value)?

Best regards,
Stefan

Report message to a moderator

Re: Loading / deserializing non-transient derived features [message #1832926 is a reply to message #1832923]

Tue, 29 September 2020 14:52

Ed Merks

Messages: 32339
Registered: July 2009

Senior Member

Transient features should not be serialized; see org.eclipse.emf.ecore.xmi.impl.XMLSaveImpl's use of isTransient guards. Typically derived features are also transient, but that's not necessary. (Note that an EcoreUtil.Copier will not copy derived feature but it will copy transient features. ) An llegalValueException typically occurs because a serialized data literal cannot be converted to a data value. That can be a problem in dynamic models where there is limited support for data type conversion, e.g., using to String and using a String-valued constructor. I'm not sure if OCLInEcore supports specifying the data conversion method the way Xcore does...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Loading / deserializing non-transient derived features [message #1832965 is a reply to message #1832926]

Wed, 30 September 2020 07:04

Ed Willink

Messages: 7467
Registered: July 2009

Senior Member

Hi

I'm not sure how OCLinEcore matches Xcore for DataType conversions either.

In principle OCLinEcore provides 100% equivalence between text and *.ecore with syntax sugar and validation for many known idioms, particularly those related to embedded OCL.Any EAnnotation conversion code can be expressed using the backstop OCLinEcore annotation support. Once I see a real example of non-manual code for EDataType conversions, I may offer a syntax sugar. For now [1] suggests that some early thoughts hit some awkward but not insurmountable hurdles. Needs a motivating use case to bring the Bugzilla back to top-of-stack. A few lines of the corresponding Xcore might suffice.

Regards

Ed Willink

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=370087

Report message to a moderator

Re: Loading / deserializing non-transient derived features [message #1832970 is a reply to message #1832965]

Wed, 30 September 2020 08:11

Ed Merks

Messages: 32339
Registered: July 2009

Senior Member

At the end of this section:

https://wiki.eclipse.org/Xcore#Specifying_a_Data_Type

it shows how the create/convert bodies can be specified for an EDataType.

Xcore, in org.eclipse.emf.ecore.xcore.util.XcoreEcoreBuilder.getEDataType(XDataType), uses org.eclipse.emf.ecore.EDataType.Internal.setConversionDelegate(ConversionDelegate) and then org.eclipse.emf.ecore.util.EcoreUtil.getConversionDelegateFactory(EDataType) can find the logic for dynamically interpreting the XBase bodies so that this works for dynamic models.

Of course this assumes the data type's class is actually available in the running IDE.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Loading / deserializing non-transient derived features [message #1833104 is a reply to message #1832970]

Fri, 02 October 2020 10:20

Stefan John

Messages: 17
Registered: March 2018

Junior Member

I wasn't aware that this could be an OCLinEcore related problem as I somehow expected problems when trying to load derived attribute values from a serialized model. Now, I am even a bit puzzled that EMF does not seem to care about the derived setting when loading a serialized attribute. The respective attribute value is even accepted and loaded from a (manually adapted) serialized model when the attribute itself is set to transient. Additionally, In the generated meta model code there is no special treatment of the derived value. I would have expected sort of an UnsupportedOperationException for the setter (as generated by OCLinEcore).
Is my assumption correct that with bare EMF the modeler is solely responsible for treating those settings right (in the model and or code using the model)?

Best regards,
Stefan

PS: The above mentioned exception with OCLinEcore occurs for any standard data type (EInt, EDouble...). The problem is not related to any custom data types.

Report message to a moderator

Re: Loading / deserializing non-transient derived features [message #1833109 is a reply to message #1833104]

Fri, 02 October 2020 12:01

Ed Willink

Messages: 7467
Registered: July 2009

Senior Member

Hi

I don't see how this is an OCLinEcore issue. OCLinEcore just gives you an alternative entry mechanism for your *.ecore file. The problem is ensuring that your selection of changeable/derived/opposite/resolveProxies/transient/volatile corresponds to one for which EMF gives useful functionality.

If you have an example where the configuration specified n OCLinEcore fails to map that through to its equivalent in *.ecore, please post it here or in an OCL Bugzilla.

Similarly if you have an example *.ecore file that silently does something stupid, then please raise an EMF Bugzilla so that a missing validation error/warning can be rectified.

Regards

Ed Willink

Report message to a moderator

Re: Loading / deserializing non-transient derived features [message #1833195 is a reply to message #1833109]

Tue, 06 October 2020 11:06

Stefan John

Messages: 17
Registered: March 2018

Junior Member

@Ed W.: Two things made me think that it is an OCLinEcore issue. The other Ed's original answer and the fact that the exception does not occur when I use derived value attributes without an OCLinEcore implementation.

Looking at the stack trace and code, now, I realize that XMLHandler tries to call setFeatureValue() when it reads a persisted attribute regardless of the attributes settings. As a consequence the OCLinEcore implementation of derived attributes throws an UnsupportedOperationException (wrapped by IllegalValueException in XMLHandler). In my opinion the XML handlers should be responsible for not trying to set a derived attribute in the first place.

If I find time, I could raise an issue on the EMF bugzilla. I just thought, the forum might be the better spot to clarify if or why this behavior might be intended and if a feature request even makes sense. After all, I feel like I still just scratch on the sruface of EMF and might have missed something.

Best regards,
Stefan

Report message to a moderator

Previous Topic:	[CDO] Official Releases
Next Topic:	EMF Generator switches from generating Literals to Methods

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sun May 22 13:20:40 GMT 2022

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter