Home » Modeling » EMF » [CDO] Tutorial on writing org.eclipse.emf.cdo.server.IStore implementation?
|
| 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   |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| 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 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| 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 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| 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 |
 Ed Merks
Messages: 33141
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| 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 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Apr 25 21:15:34 GMT 2024
Powered by FUDForum. Page generated in 0.04399 seconds |
] 
Search
Help
Register
Login
Home
