Hi, *FYI* You may like to look at the Hibernate OGM(Object to Grid Mapping) project. http://docs.jboss.org/hibernate/ogm/3.0/reference/en-US/html_single/#ogm-ho… Unfortunately the "dialect" for Cassandra is yet a work in progress. Full support is available for Infinispan data grid. Thanks Sasinda. On Mon, Sep 17, 2012 at 12:19 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com > On Sat, Sep 15, 2012 at 8:52 AM, Vincent Massol <vincent(a)massol.net> > > Hi devs, > > > > Just wanted to share my vision of how we should tackle migrating to the > new Model. I see the following steps: > > > > * Step 1: Define new model interfaces (status: in progress) > > * Step 2: Implement a "bridged" version which uses the oldcore (status: > in progress). > > * Step 3: Start moving code to use the new API as the new API and its > implementation progress. Note: we should start using the produce of step1 > and step2 ASAP to tune the details (status: not started) > > * Step 4: At the same time, start a new implementation based on a RDBMS > (probably hibernate-based, to be decided) (status: not started). I'd also > like that we start other implementations not based on a RDBMS just to prove > that it works with other storages. Ideally I'd like some NoSQL impl (Caleb > maybe?) and I'd also like to try a Git-based implementation (using jgit) > > * Step 5: Deprecate all our search apis located in XWikiHibernateStore > and make everyone use the new QueryManager module. This needs some tuning > on the QueryManager for missing stuff but that's doable (I need to send > some proposal on missing stuff). (status: in progress). The idea here is to > decouple search from storage. Note that we'll need to write some translator > from HQL to XWQL or the new search query language. > > * Step 6: As we progress in step 2, 3, 4, introduce a configuration > parameter to decide which implementation to use ("bridged", etc) so that > users can start playing with new implementations (status: not started) > > * Step 7: Rewrite a new Importer/Exporter that exports everything (all > the data in the current DB) + all configuration files/data. To see what we > are currently not exporting, see > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Backup#HUsingtheXWikiEx… new exporter should probably be based on the XWiki Streams module > being developed here: https://github.com/xwiki-contrib/wiki-stream(status: in progress but not active) > > * Step 8: When users want to migrate from one implementation ("bridged" > for ex) to a new implementation they export their wiki, set the new > implementation in the configuration file and reimport. (status: not started) > > Sounds good but just to be clear it's not steps that has to be fully > completed one after another, right ? > > > > > For me Step3 can almost begin (I probably need one or 2 more weeks to be > ready to have some use cases implemented and I'll send a vote to merge my > work in feature-newmodel branch in master - Would be good if you guys start > looking at it and give comments to be ready for this). > > Yes we need to start step3 ASAP (I insist on the fact that it does not > require steps 1 and 2 to be fully completed, we should keep the API > experimental as long as we don't are fully happy with it), that's the > only way to do a good API for us IMO. > > > > > Then we need volunteer for Step 4 for: > > * new RDBMS implementation. Who? > > > * git implementation. Vincent > > > > WDYT about the plan? > > > > In term of time required it's probably going to take us about a year to > have a first working version for all the steps by working at a leisurely > pace. > > I would say probably more than that unless we really push on it. > > > > > Thanks > > -Vincent > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

On 09/19/12 13:09, Caleb James DeLisle wrote: +1 Yes and that would be the same if we go Hibernate/Hibernate OGM. One thing to weight is which standard we use underneath. JPA seems to have more active Open Source implementations, so that would mean a stronger intermediary mapping layer that can potentially be shared for multiple vendors (hibernate, DN, etc.). By opposition, there seems to be only DataNucleus as a JDO 3 implementation, but it has the advantage to be more thought out to be backed by any kind of datastore, and DN brings a lot such implementations (though it does not support Cassandra, if we decide to go for Cassandra, it means we support the DN/Cassandra plugin ourselves). +1 Jerome