Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CDO model evolution strategy(Looking for thoughts on our proposed model evolution strategy.)
CDO model evolution strategy [message #1058896] Wed, 15 May 2013 11:09 Go to next message
Kyle B is currently offline Kyle B
Messages: 3
Registered: April 2013
Junior Member
Hello,

We are currently in the process of migrating our application to use the CDO framework. For the past few weeks I have been investigating how to handle model evolution.

Our meta-models change very frequently so it would be safe to say we will need to evolve the CDO model with each version upgrade. I have investigated some of the suggestions others have posted on this forum, but none seem to fit our needs (backup/restore, copy plugin with new nsuri, dump sql).

The approach I have been investigating involves executing SQL commands to the database to update the table structures and updating the CDO meta-model tables to reflect the new changes. The model changes will either be detected using EMF compare, or having a method where the developers will describe the changes manually.

I have manually tested this approach with several different types of model changes and have been successful so far, I was wondering if anyone more experienced with CDO might be able to foresee a pitfall?

Thank you,
Kyle
Re: CDO model evolution strategy [message #1058979 is a reply to message #1058896] Thu, 16 May 2013 02:42 Go to previous messageGo to next message
Per Sterner is currently offline Per Sterner
Messages: 48
Registered: October 2011
Member
Hi,

We are also in the same situation. Until now, we could reimport the data from the old storage.

I am also interested in the the SQL-command migratioen implementation. I have only tried to migrate a Eclass movement to another EPackage. There I only changed the column 'cdo_class' in the 'cdo_objects' Table. Although I thought it would be nice, if the cdo_class in that table would only be a reference Smile

I am also interested if there are pitfalls. And perhaps we should cooperate with this migration functionality, so that a lot migration-cases are covered.

Regards,

Per Sterner
Re: CDO model evolution strategy [message #1059277 is a reply to message #1058979] Thu, 16 May 2013 16:00 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe Bouhier
Messages: 695
Registered: July 2009
Senior Member
Hello,

It's more and more obvious many are looking for a solution for this.
From Eike, I understand he wants to do it, if only properly funded. But
this is is tricky for various (Including myself) in monetary terms, but
I can donate coding time. We will obviously need Eike's mentoring. (I am
pretty sure, he knows how to attack this problem).

I have started to look into it myself, my approach is to produce a diff
of the meta models, and use the diff to migrate the data. I don't want
to do it SQL based, as the CDO logic, needs to be in the loop I believe.
(This is very much from the gut..hehe) . I have studied the
export/import to XML code, which is some sort of middle ground between
the CDO API, and SQL. I have started to experiment emulating the
export/import behavior and applying the diffs, but no where near a real
solution...

Eike, would you be willing to mentor a solution, which would make it in
CDO 4.4? (I followed your discussions rgd PDE and fragments for 4.3...so
you must be other things on your mind!).

Cheers Christophe


On 16-05-13 08:42, Per Sterner wrote:
> Hi,
>
> We are also in the same situation. Until now, we could reimport the data
> from the old storage.
>
> I am also interested in the the SQL-command migratioen implementation. I
> have only tried to migrate a Eclass movement to another EPackage. There
> I only changed the column 'cdo_class' in the 'cdo_objects' Table.
> Although I thought it would be nice, if the cdo_class in that table
> would only be a reference :)
>
> I am also interested if there are pitfalls. And perhaps we should
> cooperate with this migration functionality, so that a lot
> migration-cases are covered.
>
> Regards,
>
> Per Sterner
[CDO] Re: CDO model evolution strategy [message #1059398 is a reply to message #1059277] Fri, 17 May 2013 18:19 Go to previous messageGo to next message
Warwick Burrows is currently offline Warwick Burrows
Messages: 84
Registered: July 2009
Location: Austin, TX
Member
Guys, this thread may not come to Eike's attention without [CDO] in the title. He did tell me once that I should have added that to the title of a post to this forum. I'll update the title in my reply just in case.

Oh and I'm also interested in a model evolution strategy as we've gone to production with CDO but have managed to avoid model changes up to this point. That won't last for long.

Warwick

Re: [CDO] Re: CDO model evolution strategy [message #1059416 is a reply to message #1059398] Sat, 18 May 2013 02:06 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5163
Registered: July 2009
Senior Member
Am 18.05.2013 00:19, schrieb Warwick Burrows:
> Guys, this thread may not come to Eike's attention without [CDO] in the title. He did tell me once that I should have
> added that to the title of a post to this forum. I'll update the title in my reply just in case.
Thank you, but I have notice it before. I have a Thunderbird filter that highlights all posts with CDO or Net4j in the
subject ;-)

These days I'm very busy with preparing next month's release and this particular subject (model evolution support) has
been discussed a lot already. It's definitely on my wish list for 4.3.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> Oh and I'm also interested in a model evolution strategy as we've gone to production with CDO but have managed to
> avoid model changes up to this point. That won't last for long.
>
> Warwick
>
>
Previous Topic:[CDO] revisions or versions list.
Next Topic:Xcore and contains of referenced model
Goto Forum:
  


Current Time: Tue May 28 11:43:30 EDT 2013

Powered by FUDForum. Page generated in 0.01903 seconds