| CDO model evolution strategy [message #1058896] |
Wed, 15 May 2013 11:09  |
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 #1059277 is a reply to message #1058979] |
Thu, 16 May 2013 16:00   |
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
|
|
|
|
| Re: [CDO] Re: CDO model evolution strategy [message #1059416 is a reply to message #1059398] |
Sat, 18 May 2013 02:06  |
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
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.01910 seconds