2011/5/12 Nicolas Helleringer <nicolas.hellerin...@gmail.com>: > I do like Bucket. It more 'free' than Database that people do associate to > much with SQL and relational (who remember that a database CAN be non > relational ?) and than Cache which seems to retrictive in my point of view. > Regards, > Niko
+1 Sanne > > 2011/5/12 Emmanuel Bernard <emman...@hibernate.org> >> >> Let me summarize, >> GridMap is the equivalent of Cache, right? >> I agree that Map is not the right representation, plus >> Map<Key,Map<String,Object>> is ugly. So +1 for a dedicated object. >> >> I think we could use: >> - Cache >> - Database >> - Bucket >> >> Note a fan of GridMap as it won't make sense for the post key/value >> >> On 11 mai 2011, at 17:24, Sanne Grinovero wrote: >> >> > 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 >> >> >> _______________________________________________ >> 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
