Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Handling XMI Documents Serialized from a Different Version of Your Model.
Handling XMI Documents Serialized from a Different Version of Your Model. [message #431243] Sun, 05 July 2009 10:48 Go to next message
Priya Missing name is currently offline Priya Missing nameFriend
Messages: 14
Registered: July 2009
Junior Member
Hi,

I am a newbie to EMF, I have an xmi that is serialized from an older
version of model.Now I have an application that knows how to desrialize an
xmi that is serialized from newer version. But I want to be able to
deserialize the xmi from the older version of the model, so that I can
persist that data into the repository that is built using the newer
version of the model.

Any help will be highly appreciated.

Thanks in advance
Priya
Re: Handling XMI Documents Serialized from a Different Version of Your Model. [message #431244 is a reply to message #431243] Sun, 05 July 2009 12:19 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30679
Registered: July 2009
Senior Member
Priya,

There are a number of different possible approaches, but given you've
not described even a single difference between the versions, I don't
even have idea of how you could tell the versions apart. Of course if
you're making sure the model changes are binary compatible, you'd not
have a problem in the first place.

How about providing a bit more detail...


Priya wrote:
> Hi,
>
> I am a newbie to EMF, I have an xmi that is serialized from an older
> version of model.Now I have an application that knows how to
> desrialize an xmi that is serialized from newer version. But I want to
> be able to deserialize the xmi from the older version of the model, so
> that I can persist that data into the repository that is built using
> the newer version of the model.
>
> Any help will be highly appreciated.
>
> Thanks in advance
> Priya
Re: Handling XMI Documents Serialized from a Different Version of Your Model. [message #431245 is a reply to message #431244] Sun, 05 July 2009 15:15 Go to previous messageGo to next message
Priya Missing name is currently offline Priya Missing nameFriend
Messages: 14
Registered: July 2009
Junior Member
Hi,

Actually, each model is persisted into a database respository such that
each modeled class is represented in the form of a table.Following are few
of the differences between the versions of the models :
1.an attribute in a modeled class is dropped in the newer version of the
model.(which means a column from one of the tables is dropped in the newer
version of model)
2.similary, a new attribute is added to a modeled class in the newer
version of the model.

Please let me know if any other information is needed.
Thanks,
Priya
Re: Handling XMI Documents Serialized from a Different Version of Your Model. [message #431246 is a reply to message #431244] Sun, 05 July 2009 15:21 Go to previous messageGo to next message
Priya Missing name is currently offline Priya Missing nameFriend
Messages: 14
Registered: July 2009
Junior Member
Hi,

Following are some of the differences:
1.An attribute is dropped from a modeled class in the newer version of the
model
2.Similary, a new attribute is added to a modeled class in the newer
version of the model.

Please, let me know if any othe rinformation is needed.
Thanks,
Priya

Ed Merks wrote:

> Priya,

> There are a number of different possible approaches, but given you've
> not described even a single difference between the versions, I don't
> even have idea of how you could tell the versions apart. Of course if
> you're making sure the model changes are binary compatible, you'd not
> have a problem in the first place.

> How about providing a bit more detail...


> Priya wrote:
>> Hi,
>>
>> I am a newbie to EMF, I have an xmi that is serialized from an older
>> version of model.Now I have an application that knows how to
>> desrialize an xmi that is serialized from newer version. But I want to
>> be able to deserialize the xmi from the older version of the model, so
>> that I can persist that data into the repository that is built using
>> the newer version of the model.
>>
>> Any help will be highly appreciated.
>>
>> Thanks in advance
>> Priya
Re: Handling XMI Documents Serialized from a Different Version of Your Model. [message #431247 is a reply to message #431245] Sun, 05 July 2009 15:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30679
Registered: July 2009
Senior Member
Priya,

Comments below.

Priya wrote:
> Hi,
>
> Actually, each model is persisted into a database respository such
> that each modeled class is represented in the form of a table.
This makes it sound like you question is more one of data base evolution
than about XMI? How does your question relate to XMI given this comment
about data base tables?
> Following are few of the differences between the versions of the models :
> 1.an attribute in a modeled class is dropped in the newer version of
> the model.(which means a column from one of the tables is dropped in
> the newer version of model)
So delete the column from the data base and the feature from the model
and you're done? In terms of deserializing XMI, this feature would be
useful:

/**
* This options allows you to record unknown features during
deserialization/loading.
* The default is <code>Boolean.FALSE</code> unless set to
<code>Boolean.TRUE</code> explicitly.
* The unknown features and their values can be accessed via
getEObjectToExtensionMap().
* @see #getEObjectToExtensionMap()
*/
String OPTION_RECORD_UNKNOWN_FEATURE = "RECORD_UNKNOWN_FEATURE";

> 2.similary, a new attribute is added to a modeled class in the newer
> version of the model.
In terms of XMI, this isn't a problem. The feature will simply not be
populated during deserialization because it's not present in the
serialization. Once it's been set, it will be serialized...
>
> Please let me know if any other information is needed.
> Thanks,
> Priya
>
Re: Handling XMI Documents Serialized from a Different Version of Your Model. [message #431250 is a reply to message #431247] Mon, 06 July 2009 04:59 Go to previous messageGo to next message
Priya Missing name is currently offline Priya Missing nameFriend
Messages: 14
Registered: July 2009
Junior Member
Hi,

Let me first confirm my understanding.

Now, the xmi I have is something that was generated with an older version
of model and there are some differences between the older and newer
versions of the model.From your reponses for those of the differences
between versions of models, below, what I understand is if attributes are
dropped in a modeled class in the newer version of the model, then while
parsing the input xmi, that attribute will not be read at all(because that
attribute is not present in the newer model), and on the other hand, if a
new attribute is added to a modeled class in a newer version of the model,
then that attribute will not be populated unless there is some default
value specified(because that attribute is not present in the input xmi).So
effectively, there should not be any problem parsing an xmi , in such
cases, generated from older versions of a model.So far so good, but the
other kind of differences between newer and older versions of models could
be
1.The name of a modeled class is changed between those two versions of the
model
2.The name of an attribute in a modeled class is changed between those
versions of model
Please help me understand , in the case of above differences, what
problems will surface when converting the xmi into eobjects (after I load
the xmi, I get a list of eobjects by calling getContents on
XMIResourceImpl, and persist those eobjects in to a database)and if they
surface how they can be resolved.

Also, if you point me to some material, that explains how the xmi is
converted into eobjects, that will help a lot.
Thanks,
Priya




Ed Merks wrote:

> Priya,

> Comments below.

> Priya wrote:
>> Hi,
>>
>> Actually, each model is persisted into a database respository such
>> that each modeled class is represented in the form of a table.
> This makes it sound like you question is more one of data base evolution
> than about XMI? How does your question relate to XMI given this comment
> about data base tables?
>> Following are few of the differences between the versions of the models :
>> 1.an attribute in a modeled class is dropped in the newer version of
>> the model.(which means a column from one of the tables is dropped in
>> the newer version of model)
> So delete the column from the data base and the feature from the model
> and you're done? In terms of deserializing XMI, this feature would be
> useful:

> /**
> * This options allows you to record unknown features during
> deserialization/loading.
> * The default is <code>Boolean.FALSE</code> unless set to
> <code>Boolean.TRUE</code> explicitly.
> * The unknown features and their values can be accessed via
> getEObjectToExtensionMap().
> * @see #getEObjectToExtensionMap()
> */
> String OPTION_RECORD_UNKNOWN_FEATURE = "RECORD_UNKNOWN_FEATURE";

>> 2.similary, a new attribute is added to a modeled class in the newer
>> version of the model.
> In terms of XMI, this isn't a problem. The feature will simply not be
> populated during deserialization because it's not present in the
> serialization. Once it's been set, it will be serialized...
>>
>> Please let me know if any other information is needed.
>> Thanks,
>> Priya
>>
Re: Handling XMI Documents Serialized from a Different Version of Your Model. [message #431251 is a reply to message #431250] Mon, 06 July 2009 10:32 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30679
Registered: July 2009
Senior Member
Priya,

Comments below.


Priya wrote:
> Hi,
>
> Let me first confirm my understanding.
>
> Now, the xmi I have is something that was generated with an older
> version of model and there are some differences between the older and
> newer versions of the model.From your reponses for those of the
> differences between versions of models, below, what I understand is if
> attributes are dropped in a modeled class in the newer version of the
> model, then while parsing the input xmi, that attribute will not be
> read at all(because that attribute is not present in the newer model),
Yes, and the deserializer will by default complain about it by throwing
an exception at the end of the processing. It will however has read the
complete model as far as all the information that is properly recognized.
> and on the other hand, if a new attribute is added to a modeled class
> in a newer version of the model, then that attribute will not be
> populated unless there is some default value specified(because that
> attribute is not present in the input xmi).
Exactly.
> So effectively, there should not be any problem parsing an xmi , in
> such cases, generated from older versions of a model.
Yes, other than suppressing exceptions about data that's doesn't fit the
model.
> So far so good, but the other kind of differences between newer and
> older versions of models could be
> 1.The name of a modeled class is changed between those two versions of
> the model
The names of classes only appear on the root element(s) of the XMI
serialization or in xsi:type/xmi:type, and in that case only when the
serialized object's type is more derived than the type expected by the
feature.
> 2.The name of an attribute in a modeled class is changed between those
> versions of model
This will affect the element/attribute name used in the feature.
> Please help me understand , in the case of above differences, what
> problems will surface when converting the xmi into eobjects (after I
> load the xmi, I get a list of eobjects by calling getContents on
> XMIResourceImpl, and persist those eobjects in to a database)and if
> they surface how they can be resolved.
These will cause problems for sure. But the could be quite easily
addressed by using OPTION_EXTENDED_META_DATA while loading, and using a
specialized instance of BasicExtendedMetaData where you specialize
things like getType/getElement/getAttribute so that given the old name,
you return the proper type/feature with the new name.
>
> Also, if you point me to some material, that explains how the xmi is
> converted into eobjects, that will help a lot.
There is no material I know of beyond what's listed on the documentation
page. There's nothing like the debugger, your best friend, and working
code to answer all life's questions though.
> Thanks,
> Priya
>
>
>
>
> Ed Merks wrote:
>
>> Priya,
>
>> Comments below.
>
>> Priya wrote:
>>> Hi,
>>>
>>> Actually, each model is persisted into a database respository such
>>> that each modeled class is represented in the form of a table.
>> This makes it sound like you question is more one of data base
>> evolution than about XMI? How does your question relate to XMI given
>> this comment about data base tables?
>>> Following are few of the differences between the versions of the
>>> models :
>>> 1.an attribute in a modeled class is dropped in the newer version of
>>> the model.(which means a column from one of the tables is dropped in
>>> the newer version of model)
>> So delete the column from the data base and the feature from the
>> model and you're done? In terms of deserializing XMI, this feature
>> would be useful:
>
>> /**
>> * This options allows you to record unknown features during
>> deserialization/loading.
>> * The default is <code>Boolean.FALSE</code> unless set to
>> <code>Boolean.TRUE</code> explicitly.
>> * The unknown features and their values can be accessed via
>> getEObjectToExtensionMap().
>> * @see #getEObjectToExtensionMap() */
>> String OPTION_RECORD_UNKNOWN_FEATURE = "RECORD_UNKNOWN_FEATURE";
>
>>> 2.similary, a new attribute is added to a modeled class in the newer
>>> version of the model.
>> In terms of XMI, this isn't a problem. The feature will simply not
>> be populated during deserialization because it's not present in the
>> serialization. Once it's been set, it will be serialized...
>>>
>>> Please let me know if any other information is needed.
>>> Thanks,
>>> Priya
>>>
>
>
Previous Topic:[CDO] A lock that is not automatically released by a commit
Next Topic:[TENEO] Illegal attempt to associate a collection with two open sessions
Goto Forum:
  


Current Time: Thu Dec 05 17:24:37 GMT 2019

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

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

Back to the top