Another one is Datastore I guess. The problem is that we put associations and entities in different datastores (at the moment at least).
On 12 mai 2011, at 19:44, Nicolas Helleringer wrote: > 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 > > 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
