Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Persistent feature of type EJavaObject (i.e. storing a plain java obj in an EMF model)
Persistent feature of type EJavaObject (i.e. storing a plain java obj in an EMF model) [message #633987] Wed, 20 October 2010 08:03 Go to next message
Cristian Spiescu is currently offline Cristian SpiescuFriend
Messages: 83
Registered: July 2009
Member
Hello,

I have an EMF class that has an attribute testObj:EJavaObject. This (persistent) attribute should be able to hold primitive types (e.g. boolean, string, int), or some simple EMF objects (e.g. VisibiliryKind enum - from the UML metamodel), or a list of EMF objects.

I noticed that this doesn't seem to work out of the box: setting:
se.setTestObj("test");

results in a serialization of this form:
<packagedElement xmi:type= ..... testObj="ACED000574000474657374">


I know that there are some methods that can serialize/deserialize an object to string. Is there something I should do to convince the load/save mechanism to use them (instead of the normal java serialization - or at least I think that's what happens when "test" -> "ACED00...")?

PS: what I want to achieve is somehow similar with the FeatureChange.value attribute (from emf.ecore.change metamodel). However, it has some drawbacks I'd like to avoid:

* .value is a derived feature; its hand written implementation converts the value to string and stores it in valueString:EString. I'm wondering if I could avoid "hand-writing", because for this case it impacts in a certain way the general architecture of my app.

* the above implementation uses indeed EcoreUtil.convertToString() because it knows the EDataType of the value; it's not necessarily my case (or perhaps there's a way of determining the EDataType from a Java instance?

Thanks in advance for any hints.
Best regards,
Cristian.

Re: Persistent feature of type EJavaObject (i.e. storing a plain java obj in an EMF model) [message #634132 is a reply to message #633987] Wed, 20 October 2010 15:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
Cristian,

Comments below.


Cristian wrote:
> Hello,
>
> I have an EMF class that has an attribute testObj:EJavaObject. This
> (persistent) attribute should be able to hold primitive types (e.g.
> boolean, string, int), or some simple EMF objects (e.g. VisibiliryKind
> enum - from the UML metamodel), or a list of EMF objects.
>
> I noticed that this doesn't seem to work out of the box: setting:
> se.setTestObj("test");
> results in a serialization of this form:
> <packagedElement xmi:type= ..... testObj="ACED000574000474657374">
Yes, it uses java.io.Serializeable. Not so human readable is it?
>
> I know that there are some methods that can serialize/deserialize an
> object to string. Is there something I should do to convince the
> load/save mechanism to use them (instead of the normal java
> serialization - or at least I think that's what happens when "test" ->
> "ACED00...")?
You'd need to define your own datatype and you'd have to keep in mind
issues like, how do you tell the difference between an int value 1
verses a string value "1"...
>
> PS: what I want to achieve is somehow similar with the
> FeatureChange.value attribute (from emf.ecore.change metamodel).
> However, it has some drawbacks I'd like to avoid:
>
> * .value is a derived feature; its hand written implementation
> converts the value to string and stores it in valueString:EString. I'm
> wondering if I could avoid "hand-writing", because for this case it
> impacts in a certain way the general architecture of my app.
>
> * the above implementation uses indeed EcoreUtil.convertToString()
> because it knows the EDataType of the value; it's not necessarily my
> case (or perhaps there's a way of determining the EDataType from a
> Java instance?
On the way out, but on the way in, you'd need to be able to tell both
the data type and the literal value.
>
> Thanks in advance for any hints.
You definitely should think about creating your own EDataType which will
work for a bounded set of possible instance types and serialize in a way
that it can determine the instance type when it deserializes. Another
approach to look at is the SimpleAnyType from the XMLTypePackage. Here
you specify both the EDataType and the value and it serializes both...
> Best regards,
> Cristian.
>
>
Re: Persistent feature of type EJavaObject (i.e. storing a plain java obj in an EMF model) [message #634379 is a reply to message #634132] Thu, 21 October 2010 13:34 Go to previous message
Cristian Spiescu is currently offline Cristian SpiescuFriend
Messages: 83
Registered: July 2009
Member
Hello Ed,

You are right! A serialization/deserialization toString() cannot be done without having a datatype (i.e. logic that can properly interpret the string, because as you've said "123" could be an int, a String, an Enum).

In the end, I managed to have both the
* value:Object
* the feature:EStructuralFeature (=> I have the data type)

I am persisting both of them, so when loading, i have the datatype again.

Thanks and best regards,
Cristi.

[Updated on: Thu, 21 October 2010 13:36]

Report message to a moderator

Previous Topic:[CDO] Problem after CDO Source Installation
Next Topic:Good idea to inherit from ENamedElement and EModelElement?
Goto Forum:
  


Current Time: Sun Oct 20 02:50:23 GMT 2019

Powered by FUDForum. Page generated in 0.01808 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top