Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation?
[CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation? [message #423601] Thu, 02 October 2008 19:10 Go to next message
Oliver Wong is currently offline Oliver WongFriend
Messages: 47
Registered: July 2009
Member
We're interested in writing out own implementation of
org.eclipse.emf.cdo.server.IStore. Our implementation will probably be
similar to org.eclipse.emf.cdo.internal.server.MEMStore, except mainly
saving to disk, rather than a DB or to memory.

Are there any tutorials on writing an IStore implementation? There are
several methods for which I'm not sure what the contract is, such as
CDOIDObjectFactory getCDOIDObjectFactory(), CDOIDLibraryDescriptor
getCDOIDLibraryDescriptor(), CDOIDLibraryProvider
getCDOIDLibraryProvider(), etc.

Thanks for any help provided.
Re: [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation? [message #423604 is a reply to message #423601] Thu, 02 October 2008 19:31 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6465
Registered: July 2009
Senior Member
Oliver Wong schrieb:
> We're interested in writing out own implementation of
> org.eclipse.emf.cdo.server.IStore. Our implementation will probably be
> similar to org.eclipse.emf.cdo.internal.server.MEMStore, except mainly
> saving to disk, rather than a DB or to memory.
Interesting. Would you consider to contribute it?

>
> Are there any tutorials on writing an IStore implementation?
No, you're one of the first asking for this.
A doc contribution would be welcome, too! ;-)

> There are several methods for which I'm not sure what the contract is,
> such as CDOIDObjectFactory getCDOIDObjectFactory(),
> CDOIDLibraryDescriptor getCDOIDLibraryDescriptor(),
> CDOIDLibraryProvider getCDOIDLibraryProvider(), etc.
These are really only important for stores that want to define their own
CDOID implementation. Before I go into details about that I'd like to
know if this is what you want. If you have no imprtant arguments for own
CDOIDs I'd strongly recommend to subclass the abstract LongIDStore (all
stores except the HibernateStore currently do so). I think looking at
MEMStore and DBStore (in this order) will answer many questions. We're
here for the remaining ones ;-)

Cheers
/Eike


Re: [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation? [message #423605 is a reply to message #423604] Thu, 02 October 2008 19:33 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6465
Registered: July 2009
Senior Member
Ah, and I forgot to ask: Are you going to store XML/XMI files or a
different format?
I sometimes thought it would be cool to have something like an XMLStore
which could bring all the nice CDO features for example to the local
workspace...

Cheers
/Eike


Eike Stepper schrieb:
> Oliver Wong schrieb:
>> We're interested in writing out own implementation of
>> org.eclipse.emf.cdo.server.IStore. Our implementation will probably
>> be similar to org.eclipse.emf.cdo.internal.server.MEMStore, except
>> mainly saving to disk, rather than a DB or to memory.
> Interesting. Would you consider to contribute it?
>
>>
>> Are there any tutorials on writing an IStore implementation?
> No, you're one of the first asking for this.
> A doc contribution would be welcome, too! ;-)
>
>> There are several methods for which I'm not sure what the contract
>> is, such as CDOIDObjectFactory getCDOIDObjectFactory(),
>> CDOIDLibraryDescriptor getCDOIDLibraryDescriptor(),
>> CDOIDLibraryProvider getCDOIDLibraryProvider(), etc.
> These are really only important for stores that want to define their
> own CDOID implementation. Before I go into details about that I'd like
> to know if this is what you want. If you have no imprtant arguments
> for own CDOIDs I'd strongly recommend to subclass the abstract
> LongIDStore (all stores except the HibernateStore currently do so). I
> think looking at MEMStore and DBStore (in this order) will answer many
> questions. We're here for the remaining ones ;-)
>
> Cheers
> /Eike


Re: [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation? [message #423747 is a reply to message #423605] Mon, 06 October 2008 17:36 Go to previous messageGo to next message
Oliver Wong is currently offline Oliver WongFriend
Messages: 47
Registered: July 2009
Member
Eike Stepper wrote:
>
> Ah, and I forgot to ask: Are you going to store XML/XMI files or a
> different format?

We're not too concerned about the format the data will be stored in for
now. The two classes I'm looking at right now are
org.eclipse.emf.cdo.common.CDODataOutput and CDODataInput. It looks like
they can be given a FileInputStream and FileOutputStream, so it may end up
being whatever format those classes read and write to.

The description I got was: "a more complete memstore, with load, save,
unload, cache management, maybe log dispatch between save and then later a
full implementation for RDF"
Re: [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation? [message #423773 is a reply to message #423747] Tue, 07 October 2008 09:33 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6465
Registered: July 2009
Senior Member
Oliver Wong schrieb:
> Eike Stepper wrote:
>>
>> Ah, and I forgot to ask: Are you going to store XML/XMI files or a
>> different format?
>
> We're not too concerned about the format the data will be stored in
> for now.
I think the two most prominent choices are:
1) A reusable text format like XML
2) A performance/scalability optimized binary format

Each has its own benefits and drawbacks, so I suggest that you carefully
check your requirements before you choose.

> The two classes I'm looking at right now are
> org.eclipse.emf.cdo.common.CDODataOutput and CDODataInput. It looks
> like they can be given a FileInputStream and FileOutputStream, so it
> may end up being whatever format those classes read and write to.
I'm not sure if these are directly usable for your new store because
they are mostly intended to support the network protocol.

> The description I got was: "a more complete memstore, with load, save,
> unload, cache management, maybe log dispatch between save and then
> later a full implementation for RDF"
I think, according to its name, the MEMStore is rather complete. "MEM"
does not indicate that it caches somehow the stored data. Caching is
completely separated from the persistence aspects of the IStore. As a
consequence an IStore implementation is generally not required to be
stateful. It's really just a means to hook a mechanism into the
framework that handles the cache misses/overflows of the existing
RevisionManager. The MEMStore, in this regard, is clearly an exception
to the general rule.

Cheers
/Eike


Re: [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation? [message #423791 is a reply to message #423773] Tue, 07 October 2008 10:56 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30813
Registered: July 2009
Senior Member
Eike,

FYI, BinaryResourceImpl might be an interesting choice if speed and
size, rather than human readable form, are of the essence.


Eike Stepper wrote:
> Oliver Wong schrieb:
>> Eike Stepper wrote:
>>>
>>> Ah, and I forgot to ask: Are you going to store XML/XMI files or a
>>> different format?
>>
>> We're not too concerned about the format the data will be stored in
>> for now.
> I think the two most prominent choices are:
> 1) A reusable text format like XML
> 2) A performance/scalability optimized binary format
>
> Each has its own benefits and drawbacks, so I suggest that you
> carefully check your requirements before you choose.
>
>> The two classes I'm looking at right now are
>> org.eclipse.emf.cdo.common.CDODataOutput and CDODataInput. It looks
>> like they can be given a FileInputStream and FileOutputStream, so it
>> may end up being whatever format those classes read and write to.
> I'm not sure if these are directly usable for your new store because
> they are mostly intended to support the network protocol.
>
>> The description I got was: "a more complete memstore, with load,
>> save, unload, cache management, maybe log dispatch between save and
>> then later a full implementation for RDF"
> I think, according to its name, the MEMStore is rather complete. "MEM"
> does not indicate that it caches somehow the stored data. Caching is
> completely separated from the persistence aspects of the IStore. As a
> consequence an IStore implementation is generally not required to be
> stateful. It's really just a means to hook a mechanism into the
> framework that handles the cache misses/overflows of the existing
> RevisionManager. The MEMStore, in this regard, is clearly an exception
> to the general rule.
>
> Cheers
> /Eike
Re: [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation? [message #423801 is a reply to message #423791] Tue, 07 October 2008 11:12 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6465
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Eike,
>
> FYI, BinaryResourceImpl might be an interesting choice if speed and
> size, rather than human readable form, are of the essence.
Thank you for the hint! While the usage of any
org.eclipse.emf.ecore.resource.Resource is not necessarily excluded it
is not the "direct" approach to implement a CDO IStore. Usually an
IStore, like the whole server-side framework, does not depend on EMF.
Depending on the capability subset that a certain IStore must support
there can be features that an EMF Resource could not support out of the
box, for example PROP_SUPPORTING_REVISION_DELTAS and PROP_SUPPORTING_AUDITS.

Cheers
/Eike


>
>
> Eike Stepper wrote:
>> Oliver Wong schrieb:
>>> Eike Stepper wrote:
>>>>
>>>> Ah, and I forgot to ask: Are you going to store XML/XMI files or a
>>>> different format?
>>>
>>> We're not too concerned about the format the data will be stored in
>>> for now.
>> I think the two most prominent choices are:
>> 1) A reusable text format like XML
>> 2) A performance/scalability optimized binary format
>>
>> Each has its own benefits and drawbacks, so I suggest that you
>> carefully check your requirements before you choose.
>>
>>> The two classes I'm looking at right now are
>>> org.eclipse.emf.cdo.common.CDODataOutput and CDODataInput. It looks
>>> like they can be given a FileInputStream and FileOutputStream, so it
>>> may end up being whatever format those classes read and write to.
>> I'm not sure if these are directly usable for your new store because
>> they are mostly intended to support the network protocol.
>>
>>> The description I got was: "a more complete memstore, with load,
>>> save, unload, cache management, maybe log dispatch between save and
>>> then later a full implementation for RDF"
>> I think, according to its name, the MEMStore is rather complete.
>> "MEM" does not indicate that it caches somehow the stored data.
>> Caching is completely separated from the persistence aspects of the
>> IStore. As a consequence an IStore implementation is generally not
>> required to be stateful. It's really just a means to hook a mechanism
>> into the framework that handles the cache misses/overflows of the
>> existing RevisionManager. The MEMStore, in this regard, is clearly an
>> exception to the general rule.
>>
>> Cheers
>> /Eike


Previous Topic:[CDO] why getCreationIme is Unsupported in HibernateStore
Next Topic:EMF Stand-alone main application
Goto Forum:
  


Current Time: Thu Jan 23 01:23:05 GMT 2020

Powered by FUDForum. Page generated in 0.03091 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top