Re: [hibernate-dev] Hibernate OGM

2011/5/11 Alex Snaps <alex.snaps(a)gmail.com&gt;: > On Wednesday 11 May 2011 at 15:38, Sanne Grinovero wrote: > Hi Alex, > > thank you I'm having a look and will comment more on github directly. > I'll look into your comments and will adapt. thanks! > > > > > A first comment: I see that a big part of your patch is about > > replaceing "Cache" with "ConcurrentMap" and renaming variables to be > > consistent with this change; at the same time in the JSR-107 forum it > > seems that everybody is agreeing on *not* extending Map, while there's > > going to be something similar to a Map, this is going to be called > > "Cache", so I'd stick with our current name. > > I understand this is a bit in flux now and nothing is cast in stone, > > but at the moment it would be better to keep your patch smaller and > > avoiding these conversions, or at least keeping these refactorings as > > a separate commit. > > I think that makes sense, I actually started with neither Map nor ConcurrentMap, but some other random Grib interface. > I then saw the wiki page mentioning Map... I certainly can review this, but it does look like the plan is to have this tailored to jsr-107, I didn't know that. I'll stick to ConcurrentMap return values, but will not rename further. Sorry I didn't mean to state that we're going to support jsr-107, we should discuss that but it's unlikely in practice as we want to support more alternatives than key/value stores. I'm only mentioning it as the abstraction you're introducing now will make OGM support only Infinispan and EHCache, and they happen to have this common API which gives names the building blocks as "Cache" and "CacheManager". So for the time being there's no need to change all variable names. It will definitely be more complex when other storage engines will be added; it might be an option to use JSR-107 or JSR-347 at least for the key/value implementors but I don't think either is going to cover all of noSQL. Also even if we wanted to finish only Infinispan and EHCache, I don't think the ConcurrentMap API would be good enough, we likely need a more intrusive definition of "dialect" here. > > The plan is to build the first version of queries on top of Hibernate > > Search, so basically that's already an abstraction on top of any "Grid > > implementation" and it should work fine with EHCache as well; Lucene > > won't be able to solve all use cases though so for some cases we'll > > need to tap into special functionalities offered by the grid provider, > > but that's going to be a second step. Suggestions welcome of course! > I have seen that Hibernate Search approach, I wondered whether a real query bridge to the grid wouldn't make more sense. But I totally agree that that approach makes total sense as a first step. > > > > > As far as the "skip locking" pattern, that's currently the way to > > build a sequence generator on top of Infinispan, in case of EHCache > > you might want to suggest a totally different approach, I'd expect > > that this should be an implementation detail at the dialect level, not > > necessarily common code. > Alright, that makes sense as well... I'll look into abstracting that nicely behind the Dialect then. > > > > > Regards, > > Sanne > > > > > > 2011/5/11 Alex Snaps <alex.snaps(a)gmail.com&gt;: > > > Hey, > > > I've taken some time and, in an attempt to port Hibernate OGM to use Ehcache instead of Infinispan, abstracted it from Infinispan. > > > As the doc on that task states, I've made all calls use ConcurrentMap (rather than Map actually). I had a little trouble understanding the "Skip locking proposed by Sanne" in OgmTableGenerator.doWorkInCurrentTransactionIfAny, so that this does a simple Map.get now (that might have been a specialization for a Dialect, but couldn't understand what it was all about). > > > And finally introduced a new hibernate.grid.manager prop to instantiate the proper provider... > > > > > > The changes are available here: > > > https://github.com/alexsnaps/hibernate-ogm/commit/d0fcbffed4c4bcc2aa5208c... > > > > > > Hope that can be made useful… I also wanted to start looking into queries next. But I'll send another mail on that later. > > > Thanks, > > > Alex > > > > > > > > > -- > > > Alex Snaps <alex.snaps(a)gmail.com&gt; > > > Senior Software Engineer - Terracotta > > > http://twitter.com/alexsnaps > > > http://www.linkedin.com/in/alexsnaps > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev