|
| Re: CDO and Walking EMF [message #1738617 is a reply to message #1738611] |
Thu, 21 July 2016 12:40   |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
| Re: CDO and Walking EMF [message #1738780 is a reply to message #1738765] |
Sun, 24 July 2016 05:44 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.03456 seconds
] 
Search
Help
Register
Login
Home
