Home » Modeling » EMF » [CDO] Metamodel change -> migration path?
| [CDO] Metamodel change -> migration path? [message #426086] |
Tue, 16 December 2008 09:04  |
 Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Hi,
I don't know if this topic has been discussed earlier, but is there a
way to migrate CDO-backed data to a new metamodel?
I know that metamodels cannot be changed once stored in CDO, but is
there a way, like, to export the database contents into a file, then
delete the database, restart so the DB is created with the new metamodel
and reimport the data from the file?
Well, this should at least work, if I write my own custom data-exporter
which would not care about models and metamodels, but is this by chance
possible with the builtin CDO UI tools?
Cheers
Stefan
|
|
|
| Re: [CDO] Metamodel change -> migration path? [message #426089 is a reply to message #426086] |
Tue, 16 December 2008 09:12  |
Xingxiao Lu
Messages: 91
Registered: July 2009 |
Member |
|
|
Eike has openned a bug about this
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256856
"Stefan Winkler" <stefan.winkler-et@fernuni-hagen.de>
> Hi,
>
> I don't know if this topic has been discussed earlier, but is there a way
> to migrate CDO-backed data to a new metamodel?
> I know that metamodels cannot be changed once stored in CDO, but is there
> a way, like, to export the database contents into a file, then delete the
> database, restart so the DB is created with the new metamodel and reimport
> the data from the file?
>
> Well, this should at least work, if I write my own custom data-exporter
> which would not care about models and metamodels, but is this by chance
> possible with the builtin CDO UI tools?
>
> Cheers
> Stefan
|
|
|
| Re: [CDO] Metamodel change -> migration path? [message #426094 is a reply to message #426086] |
Tue, 16 December 2008 10:10 |
|
Stefan,
Currently CDO has neither core-level nor a UI-level support for
automatic data migration after model evolution.
As Xxlu pointed out we have started sorting our minds with respect to
the requirements and implications.
I have the feeling that the approach you sketched has some flaws. See my
inline comments...
Stefan Winkler schrieb:
> Hi,
>
> I don't know if this topic has been discussed earlier, but is there a
> way to migrate CDO-backed data to a new metamodel?
> I know that metamodels cannot be changed once stored in CDO, but is
> there a way, like, to export the database contents into a file,
This should be possible already with *backend-specific* facilities.
> then delete the database, restart so the DB is created with the new
> metamodel
I'm not sure if you really mean the DB or the repository.
This way or that way I'd say there is not meta data created or
re-created automatically.
In CDO meta data is not a self-purpose and is thus only created
*together* with the instances that need this meta data.
> and reimport the data from the file?
Well, this is the most cloudy step of the process ;-)
what exactly would you expect to happen here?
Cheers
/Eike
----
http://thegordian.blogspot.com
>
> Well, this should at least work, if I write my own custom
> data-exporter which would not care about models and metamodels, but is
> this by chance possible with the builtin CDO UI tools?
>
> Cheers
> Stefan
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Metamodel change -> migration path? [message #426110 is a reply to message #426094] |
Tue, 16 December 2008 16:00 |
Stefan Winkler
Messages: 307
Registered: July 2009
Location: Germany |
Senior Member |
|
|
Eike,
I should have been more specific. Most of my metamodel changes are
simply adding an attribute. So the migration should in Theroy be
automatable by simply assigning the values of the old objects to the new
ones and set the added attribute's value to a default.
>> then delete the database, restart so the DB is created with the new
>> metamodel
> I'm not sure if you really mean the DB or the repository.
Since I have only one repository, this should have read: drop all my
tables :-)
> This way or that way I'd say there is not meta data created or
> re-created automatically.
No, but the old package data is erased and the objects are inserted as
objects of the new model. I also should have said, that I don't care
about revised revisions :-)
>
>> and reimport the data from the file?
> Well, this is the most cloudy step of the process ;-)
> what exactly would you expect to happen here?
Well, see above. But generally, I could imagine a UI which does a best
guess for mappings and then suggests a transformation from the old model
to the new one. (old and new meaning conformant to the old/new metamodel
in this post .. I'm just being lazy ... ;-))
Cheers,
Stefan
|
|
|
| Re: [CDO] Metamodel change -> migration path? [message #426135 is a reply to message #426110] |
Wed, 17 December 2008 08:17 |
|
Stefan,
Comments below...
Stefan Winkler schrieb:
> Eike,
>
> I should have been more specific. Most of my metamodel changes are
> simply adding an attribute. So the migration should in Theroy be
> automatable by simply assigning the values of the old objects to the
> new ones and set the added attribute's value to a default.
I see.
>
>>> then delete the database, restart so the DB is created with the new
>>> metamodel
>> I'm not sure if you really mean the DB or the repository.
> Since I have only one repository, this should have read: drop all my
> tables :-)
>> This way or that way I'd say there is not meta data created or
>> re-created automatically.
> No, but the old package data is erased and the objects are inserted as
> objects of the new model.
But I still see a minor challenge there. As you know, there are two
types of tables in a DBStore-managed database:
1) System tables (repo info, package infos, class infos, ...)
2) Model tables (revision data)
If you drop *all* tables and don't have the state of the system tables
in your export (because this part will change for the new model
versions), then you need to re-create them somehow manually. Maybe it
helps to commit a dummy transaction with a dummy resource and some
classes of the new models. This would populate the system tables with
needed infos...
> I also should have said, that I don't care about revised revisions :-)
Then I suggest that you lift the priority of
253110: [DB] Support non-auditing mode
https://bugs.eclipse.org/bugs/show_bug.cgi?id=253110
:P
>>
>>> and reimport the data from the file?
>> Well, this is the most cloudy step of the process ;-)
>> what exactly would you expect to happen here?
> Well, see above. But generally, I could imagine a UI which does a best
> guess for mappings and then suggests a transformation from the old
> model to the new one. (old and new meaning conformant to the old/new
> metamodel in this post .. I'm just being lazy ... ;-))
Generally I also can imagine fancy things like UI and mapping guesses ;-)
We have this bugzilla for general discussion of this sensible topic (not
to say complex):
256856: Support model evolution
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256856
Btw. is the approach you have in mind store-specific (i.e. DBStore) or
would it act more generally on the repository level?
Cheers
/Eike
----
http://thegordian.blogspot.com
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Apr 25 12:22:17 GMT 2024
Powered by FUDForum. Page generated in 0.03468 seconds |
] 
Search
Help
Register
Login
Home
