2011/5/11 Alex Snaps <alex.sn...@gmail.com>: > Unintentionally left the ML out.
oops, sorry didn't realize that. for everyone else: please find my previous reply below; > Sanne, wrt jsr107 fair enough. I then feel that we should not leverage Map > and use a custom type that only declare what's needed (and avoids the return > value, when not required). I think that'd make it simpler, wdyt ? How should > we name that thing ? My first attempt was GridMap... So you need something like a Cache, but 1- avoid the org.infinispan package 2- provide non-return value methods (Infinispan does this setting flags in the context to avoid an explosion of methods - does EHCache have something similar?) ? GridMap sounds fine, but again it's just a temporary solution until non-grids are supported as well. Other opinions ? Sanne > On Wednesday 11 May 2011 at 16:50, Sanne Grinovero wrote: >> 2011/5/11 Alex Snaps <alex.sn...@gmail.com>: >> > 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.sn...@gmail.com>: >> > > > 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/d0fcbffed4c4bcc2aa5208c049ca5e870e07424e >> > > > >> > > > 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.sn...@gmail.com> >> > > > Senior Software Engineer - Terracotta >> > > > http://twitter.com/alexsnaps >> > > > http://www.linkedin.com/in/alexsnaps >> > > > >> > > > _______________________________________________ >> > > > hibernate-dev mailing list >> > > > hibernate-dev@lists.jboss.org >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
