On 26 March 2014 20:17, Kevin Meyer - KMZ <[email protected]> wrote: > I've been following this in the background here and just wanted confirm > something Dan said a few days ago: > > On 20 Mar 2014 at 15:59, Dan Haywood wrote: > > > So I still think it'd be worth considering wrapping up a domain service > as > > a DN StoreManager impl. I imagine that a lot of the boilerplate could be > > factored out. Just looking at the datanucleus-json implementation of > > StoreManager [1], for example, it doesn't look *too* threatening. I also > > noticed that DataNucleus has a FederatedStoreManager, so there could be a > > number of companion store managers for managing entities from these > > external systems, operating alongside any entities that Isis itself > manages > > in the regular JDO ObjectStore. > > Does this support a convenient idea of different store managers for > different entities? >
Exactly. > > I had to hack something a while ago when I needed a particular class to > be persisted with one datastore and the rest with the default. > > I ended up implementing a dummy datastore that was given to Isis, and > it decided between my special store for persistence related queries > affecting entities of my one class and the "normal" datastore for all the > others. > > It worked, but it was a hack. > > Is there a better / managed method for this with DN? > > Yes, I believe that DN's StoreManager API will exactly support this. Not to prejudge discussions, but one option is to merge core-runtime and the JDO OS together; then the JDO Store Manager API [1] replaces Isis' own ObjectStore API; and we end up shrinking the size of Isis codebase. That page [1] also references a short wiki article [2], which I've copied below for reference: Dan *The process of adding support for a new datastore is simple in concept. It has particular components that can be supported or not. You don't have to support everything at once. The following gives guidelines on how to do it* 1. *Is there a supported datastore that is similar in terms of its access ? If so, copy the existing datastore plugin (renaming packages etc). For example to support another OODB, you could take the "datanucleus-db4o" plugin as a start point. Develop the XXXStoreManager class. You are recommended to extend "org.datanucleus.store.AbstractStoreManager". Make sure you specify the getSupportedOptions() method specifying what is supported* 2. *Develop the ConnectionFactoryImpl. This provides connectivity to the datastore. If the datastore has a simple connection that you open then commit then this file will be very simple. Again, copy an existing one if there is something suitable. You are recommended to extend "org.datanucleus.store.connection.AbstractConnectionFactory"* 3. *Develop the PersistenceHandler. This provides the capability to do insert/update/delete/fetch/locate and so provides support for persistence to this datastore. You are recommended to extend "org.datanucleus.store.AbstractPersistenceHandler"* 4. *Develop the JDOQL support. Make use of the org.datanucleus.query classes. You need to decide how much of the query can be embodied in the native query language of the datastore. If you can't support some feature in the datastore native language then use the in-memory query evaluation* 5. *Add on support for other features like inheritance strategy, discriminators, version checks, type converters as they are required.* *As a guide, the basic connection, persistence could maybe be done in 2-4 days supporting "complete-table" only. To provide JDOQL in-memory capability, you could do that in very short time also since the in-memory evaluator is done and the only thing you need to do is retrieve the candidate objects (of the candidate type). To provide JDOQL in-datastore capability would take longer, how much would depend on the native query language structure for your datastore. Supporting things like other inheritance strategies may take significantly longer depending in the datastore.* [1] http://www.datanucleus.org/extensions/store_manager.html [2] http://www.datanucleus.org/servlet/wiki/display/ENG/HOWTO+Support+a+new+datastore > Regards, > Kevin >
