| EMF Object and discrepancy tolerance [message #1456657] |
Thu, 30 October 2014 15:37  |
 ModelGeek Mising name
Messages: 550
Registered: June 2011 |
Senior Member |
|
|
I have been using java serialization for persisting my POJOs in files but now i need to store my POJOs in database and needs collaboration in my application so i have decided to use CDO.
If i have saved an EMF model (either in File or in DB using CDO) and i have to do alterations in my model like add/delete/rename attributes then will i able to retirve saved models properly from saved resources?
So to be concerete let's suppose i have an ecore model and i have many saved models in db using CDO
1 - if i add a new attribute to my ecore model and regenerate model then will i be able to retrieve old models properly?
2 - if i delete an attribute to my ecore model and regenerate model then will i be able to retrieve old models properly?
3 - if i rename an attribute to my ecore model and regenerate model then will i be able to retrieve old models properly?
thanks for helping....
Cheers,
[Updated on: Thu, 30 October 2014 15:37] Report message to a moderator |
|
|
|
|
|
|
|
|
| Re: EMF Object and discrepancy tolerance [message #1461556 is a reply to message #1461506] |
Tue, 04 November 2014 17:43  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Ed,
Comments below.
On 04/11/2014 5:29 PM, Ed Willink wrote:
> Hi
>
> I think you are making your problem harder by considering it as a CDO
> problem.
CDO is quite special. The Ecore model itself is committed and fixed...
>
> If you want to allow your metamodels to evolve you have two choices.
>
> a) eager conversion to upgrade everything immediately
For CDO this involves some kind of data base migration. Perhaps as
Felix suggests, export everything to XMI and apply some conversion
logic, then create a new data base with the new model, importing all the
data...
>
> b) lazy conversion to upgrade on demand
That's just not really an option for CDO.
>
> Either way you have to code a conversion algorithm, which if you are
> lucky may be as simple as assigning default values for new properties.
With CDO, there's a database migration problem. And if you keep a
history, what happens to that?
>
> 100% eager conversion is not often practical so you have to do lazy
> conversion which to me means that you have a custom ResourceFactory
> that reads in old XMI and converts it before it becomes visible as new
> content to new code.
Again, CDO is not so purely tailorable with specialized resource factories.
>
> In CDO you may have the option to convert object by object,
No.
> which might make sense if you were using an Object repository, but
> with an underlying Relational repository a partial upgrade may play
> havoc with the indexes.
Yes.
> To me this still needs a custom ResourceFactory.
It's just doesn't boil down to the same problem with CDO...
>
> Regards
>
> Ed Willink
>
> On 04/11/2014 16:05, Felix Dorner wrote:
>> On 04/11/2014 15:59, ModelGeek Mising name wrote:
>>> thanks for support.
>>>
>>> I have been looking foe different alternative to CDO... but CDO gives a
>>> lot of features which are very important to us.
>>> For us it is important that when we add new properties to classes then
>>> objects saved using CDO remains retrievable... As you have said
>>> that it
>>> would be problematic and i have done some test which indicate the same
>>> phenomena... Is there any way we could solve this problem?
>>
>> Pragmatic (only?) approach is to export the model from CDO to say XMI,
>> migrate it somehow and then re-import it into CDO..
>>
>>> thanks again!
>>>
>>> Cheers
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.40805 seconds
] 
Search
Help
Register
Login
Home
