All this stuff is pluggable and only uses the SPI, right? Are there comparable features needed for other NoSQL/bigdata storages as well?
LieGrue, strub ----- Original Message ----- > From: Francesco Chicchiriccò <ilgro...@apache.org> > To: dev@openjpa.apache.org > Cc: > Sent: Monday, August 13, 2012 4:18 PM > Subject: Re: Experimenting with MS SQL Azure federations > > Hi all, > anyone interested in this topic? > > After the initial feasibility study, our customer is now about to > commission the whole implementation. > > We can release this under AL 2.0 and put it somewhere (apache-extras, > github), but if possible we would like to involve the OpenJPA community > in this, possibly contributing to mainstream OpenJPA code & doc. > > WDYT? > > On 30/05/2012 12.09, Francesco Chicchiriccò wrote: >> Hi all, >> one of my company (Tirasa) customers asked Fabio Martelli (in CC) and me >> to start exploring the integration between OpenJPA and MS SQL Azure >> federations. >> >> After some work we came out with [1], a sample webapp with persistence >> layer (managed by OpenJPA) on MS SQL Azure; moreover, this sample code >> makes profit of federations [2], a way to perform table partition, close >> to the "sharding" concept. >> >> SQL Azure federations were initially considered as mappable to OpenJPA >> slices: in fact, both refers to 'sharding', however with slight >> different meaning. >> OpenJPA slices provide their own mechanism to handle at application >> level distributed queries, data distribution and data replication1; SQL >> Azure federations, instead, push such aspects to database configuration >> level and empowers the ability to change some of these at runtime. >> >> For example, with OpenJPA slices can be configured so that records from >> table Person with field id value < 500 will be handled by slice1, while >> the rest will be handled by slice2, where slice1 and slice2 are two >> separated databases. This breaks the SQL Azure federations model, >> because the Person table of this example can be dynamically split at >> runtime, thus generating one or more federation members at persistence >> level. >> >> This implies that the actual federation member for a given record >> * cannot be determined by configuration -- as OpenJPA slices require, >> but only at runtime; >> * cannot be chosen at application level but is enforced by persistence >> level. >> >> At the end, SQL Azure federations provide an additional scalability >> layer and can then be seen as complementary to OpenJPA slices, rather >> then opposite. >> >> If anyone is interested, we also wrote a simple wiki page [3] about how >> to get our demo code up an running. >> Any feedback is welcome. >> >> Our customer is currently evaluating whether to extend this feasibility >> study with a complete implementation and would also like us to >> contribute such code back to OpenJPA community. >> Fabio Martelli and I are already ASF committers and PPMC members at >> Apache Syncope [4], IdM solution with persistence based on OpenJPA. >> >> WDYT? >> >> Regards. >> >> [1] https://github.com/Tirasa/protojpasqlazure/ >> [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx >> [3] https://github.com/Tirasa/protojpasqlazure/wiki/Setup >> [4] http://incubator.apache.org/syncope/ > > -- > Francesco Chicchiriccò > > ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member > http://people.apache.org/~ilgrosso/ >
