Home » Modeling » EMF » Handling XMI Documents Serialized from a Different Version of Your Model.
| | |
| 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   |
 Priya Missing name
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 #431250 is a reply to message #431247] |
Mon, 06 July 2009 04:59 |
Priya Missing name
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 |
Ed Merks
Messages: 33133
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
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 07:57:07 GMT 2024
Powered by FUDForum. Page generated in 0.02215 seconds |
] 
Search
Help
Register
Login
Home
