|
|
| Re: [Edapt][CDO] EDAPT with CDO [message #757866 is a reply to message #757329] |
Sun, 20 November 2011 15:16   |
Eclipse User |
|
|
|
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 07:42 |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.27163 seconds
Home