Eclipse Community Forums: EMF » CDO and Walking EMF

Home » Modeling » EMF » CDO and Walking EMF(How does CDO walk and EMF model)

Thu, 21 July 2016 08:06

Eclipse User

All,

I am digging through the CDO codebase and no doubt, in time, will find what I am looking for; but if someone would be so good as to speed me on my way I would appreciate it.

Somewhere CDO must walk through an EMF in order to persist it. I assume it does this with a common, consistent routine that is shared by all. How can I take advantage of that? Apologies in advance if I've missed the documentation on this.

I need to persist EMF in other ways than are supported, hence my interest. I've seen this walking done in other (not CDO) projects and even wrote a rudimentary one myself. But I'll bet the CDO project has a nice robust implementation somewhere.

Thanks

Re: CDO and Walking EMF [message #1738617 is a reply to message #1738611]

Thu, 21 July 2016 08:40

Eclipse User

Am 21.07.2016 um 15:06 schrieb Geoffry Roberts:
> All,
>
> I am digging through the CDO codebase and no doubt, in time, will find what I am looking for; but if someone would be
> so good as to speed me on my way I would appreciate it.
>
> Somewhere CDO must walk through an EMF in order to persist it. I assume it does this with a common, consistent
> routine that is shared by all. How can I take advantage of that? Apologies in advance if I've missed the
> documentation on this.
Sorry, it's really not clear to me what your looking for. Maybe you can rephrase your desire more concisely?

If by "walk through an EMF" you mean to traverse a model (sub) tree, you could use the TreeIterator tat is returned from
the eAllContents() method of the root object of that (sub) tree.

Cheers
/Eike

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

>
> I need to persist EMF in other ways than are supported, hence my interest. I've seen this walking done in other (not
> CDO) projects and even wrote a rudimentary one myself. But I'll bet the CDO project has a nice robust implementation
> somewhere.
>
> Thanks

Re: CDO and Walking EMF [message #1738765 is a reply to message #1738617]

Sat, 23 July 2016 09:52

Eclipse User

You make good points. We don't always realize when we're not being clear.

Let me go at it this way, I want to persist EMF in ways that are not currently implemented. I can of course roll my own and have done so in the past, but I think it would be better if this were done in harmony with the CDO framework. So let me ask a variant of one of the FAQs: Can we change the underlying data base to use something like <My favorite DB> instead of relational DB? and if so, can you help me get started?

I've been looking through the code for the MongoDB persistence thinking it is the most similar to what I want to do. I have yet to discover how EMF and DBObject go together. It's slow going.

Thanks

Re: CDO and Walking EMF [message #1738780 is a reply to message #1738765]

Sun, 24 July 2016 01:44

Eclipse User

Am 23.07.2016 um 16:52 schrieb Geoffry Roberts:
> You make good points. We don't always realize when we're not being clear.
>
> Let me go at it this way, I want to persist EMF in ways that are not currently implemented. I can of course roll my
> own and have done so in the past, but I think it would be better if this were done in harmony with the CDO framework.
> So let me ask a variant of one of the FAQs: Can we change the underlying data base to use something like <My favorite
> DB> instead of relational DB? and if so, can you help me get started?
Yes, that's possible by implementing org.eclipse.emf.cdo.spi.server.InternalStore, or better by extending
org.eclipse.emf.cdo.spi.server.Store or org.eclipse.emf.cdo.spi.server.LongIDStore.

You'll also have to create your custom implementation of org.eclipse.emf.cdo.server.IStoreAccessor, for example by
extending org.eclipse.emf.cdo.spi.server.StoreAccessorBase, org.eclipse.emf.cdo.spi.server.StoreAccessor, or
org.eclipse.emf.cdo.spi.server.LongIDStoreAccessor.

Beware that there's no good extender documentation, but there are quite a few examples in our code base. The
DBStore(Accessor) is the most complete store implementation.

> I've been looking through the code for the MongoDB persistence thinking it is the most similar to what I want to do.
Our MongoDBStore is very different from all the other store implementations, because MongoDB does not support
transactions with ACID properties. I.e., we can't atomically persist multiple documents for the changed EMF objects. We
rather atomically persist the commit change set as one document. Hence the MongoDBStore is a "delta store" with very
fast writing and slower reading (depending on the history that needs to be queried for each read).

> I have yet to discover how EMF and DBObject go together. It's slow going.
I'm not sure I heard of DBObject.

Cheers
/Eike

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

Previous Topic:	Skipping resolution error when loading
Next Topic:	How to suppress target namespace generation on xml resource serialization

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 09:58:10 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter