|Re: CDO and Walking EMF [message #1738780 is a reply to message #1738765]
||Sun, 24 July 2016 05:44
|| Eike Stepper
Registered: July 2009
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
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.
Powered by FUDForum
. Page generated in 0.02553 seconds