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 15:10  |
Eclipse User |
|
|
|
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 #423605 is a reply to message #423604] |
Thu, 02 October 2008 15:33  |
| Eclipse User |
|
|
|
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 #423773 is a reply to message #423747] |
Tue, 07 October 2008 05:33 |
| Eclipse User |
|
|
|
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 06:56 |
| Eclipse User |
|
|
|
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 07:12 |
| Eclipse User |
|
|
|
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
|
|
|
Goto Forum:
Current Time: Wed Jul 23 03:41:16 EDT 2025
Powered by FUDForum. Page generated in 0.60340 seconds |
Home