[Edapt][CDO] EDAPT with CDO [message #757329] |
Thu, 17 November 2011 18:08 |
Alexandre Borgoltz Messages: 31 Registered: July 2009 Location: France |
Member |
|
|
Hey,
I have been successfully using COPE/Edapt to migrate EMF models when Resources are files with XML in them.
I am starting a new project and we are using CDO as the back-end. CDO is just GREAT so far - except I cannot manage to migrate my model easily after a metamodel evolution.
I am using Indigo, and Edapt seems to be uncompatible with CDOResource. For instance its ReleaseUtils class explicitely considers resource uris as file uris and evenmore as XML Files:
/** Extract the namespace URI from a model. */
public static String getNamespaceURI(URI uri) {
return getNamespaceURI_SAX(URIUtils.getJavaFile(uri));
}
Edapt guys: Is there anyway I can have Edapt work with CDO?
CDO guys: Is there something else than Edapt that I should do to migrate my models in CDO when the metamodel changes?
I thank you in advance!
[Updated on: Fri, 18 November 2011 08:09] Report message to a moderator
|
|
|
Re: [Edapt][CDO] EDAPT with CDO [message #757864 is a reply to message #757329] |
Thu, 17 November 2011 20:25 |
|
Am 17.11.2011 19:08, schrieb Alexandre Borgoltz:
> Hey,
>
> I have been successfully using COPE/Edapt to migrate EMF models when Resources are files with XML in them.
>
> I am starting a new project and we are using CDO as the back-end. CDO is just GREAT so far
Thanks ;-)
> - except I cannot manage to migrate my model easily after a metamodel evolution.
Yeah, that's a known issue. Currently CDO does not support automatic model evolution or schema/instance migration, see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256856
The new backup/restore mechanism can help you a little bit:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=330235
https://bugs.eclipse.org/bugs/show_bug.cgi?id=332355
Since the cost of this feature (in the light of arbitrary data backends and features like auditing and branching) is
unusually high I'm still waiting for a customer to approve the needed budget.
>
> I am using Indigo, and Edapt seems to be uncompatible with CDOResource. For instance its ReleaseUtils class
> explicitely considers resource uris as file uris and event as XML Files:
I'm not an Edapt expert, yet, but that doesn't sounds right.
>
> /** Extract the namespace URI from a model. */
> public static String getNamespaceURI(URI uri) {
> return getNamespaceURI_SAX(URIUtils.getJavaFile(uri));
> }
>
> Edapt guys: Is there anyway I can have Edapt work with CDO? CDO guys: Is there something else than Edapt that I should
> do to migrate my models in CDO when the metamodel changes?
As a temporary "workaround" I already posted some hints to the EMF newsgroup. Please filter for "evolution".
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [Edapt][CDO] EDAPT with CDO [message #757866 is a reply to message #757329] |
Sun, 20 November 2011 20:16 |
Markus Herrmannsdoerfer Messages: 50 Registered: July 2009 |
Member |
|
|
Hi Alexandre,
Am 17.11.2011 19:08, schrieb Alexandre Borgoltz:
> Hey,
>
> I have been successfully using COPE/Edapt to migrate EMF models when
> Resources are files with XML in them.
Good to hear.
>
> I am starting a new project and we are using CDO as the back-end. CDO is
> just GREAT so far - except I cannot manage to migrate my model easily
> after a metamodel evolution.
Conceptually, it should be possible to use Edapt with CDO. In Edapt,
models are migrated using a special intermediate structure which is
based on a metamodel. You would need to make the source metamodel, the
intermediate metamodel and the target metamodel available in CDO. The
source model is transferred to the intermediate structure, then the
migration is performed and finally the model is transferred into the
target metamodel. This functionality is already available. However, I
have never tried to use it with CDO. Unfortunately, I do not have the
resources at the moment to do it myself. However, I can help you if you
like. Also we can try to start a technical discussion with Eike.
>
> I am using Indigo, and Edapt seems to be uncompatible with CDOResource.
> For instance its ReleaseUtils class explicitely considers resource uris
> as file uris and event as XML Files:
>
> /** Extract the namespace URI from a model. */
> public static String getNamespaceURI(URI uri) {
> return getNamespaceURI_SAX(URIUtils.getJavaFile(uri));
> }
This is true. But you do not have to use this method to obtain the
release to which your model conforms. You can provide your own
implementation.
>
> Edapt guys: Is there anyway I can have Edapt work with CDO? CDO guys: Is
> there something else than Edapt that I should do to migrate my models in
> CDO when the metamodel changes?
>
> I thank you in advance!
>
Sorry that I cannot help you more at the moment.
Cheers,
Markus
|
|
|
|
Re: [Edapt][CDO] EDAPT with CDO [message #912913 is a reply to message #912872] |
Fri, 14 September 2012 11:42 |
|
Am 14.09.2012 12:07, schrieb Robert Wagner:
> Hi all,
>
> we are using CDO in our project and it works really fine.
Good ;-)
> However, we are also running into the metamodel evolution problem. I have already read about the possible workarounds,
> e.g. the backup/restore mechanism or the manual migration described in bug 256856.
>
> Now, my questions are:
> How is the performance of the suggested workarounds. Has anyone some data (how large was the migrated CDO repository
> and how much time does the migration need)?
> In order to migrate a quite large CDO repository, what is the recommendation for that case?
We're lacking of such information for huge repositories. It would be awesome if you could post yours here.
Both the export and the import mechansims are designed carefully, with large repositories in mind. There are no EObjects
and there is no object reference resolution involved. They operate on CDO's lowest and quickest level. Even large
objects (blobs and clobs) are streamed directly from the database into the XML export file and vice versa.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03643 seconds