[hibernate-dev] Hibernate OGM

Fri May 13 10:13:24 EDT 2011

On Thursday 12 May 2011 at 19:49, Sanne Grinovero wrote:
2011/5/12 Nicolas Helleringer <nicolas.helleringer at 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
> 
Yep. Bucket seems like the less "associated" in this scenario indeed, if that's an agreement, I'll go for that!

> Sanne
> 
> > 
> > 2011/5/12 Emmanuel Bernard <emmanuel at 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.snaps at 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.snaps at 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.snaps at 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.snaps at gmail.com>
> > > > > > > > > Senior Software Engineer - Terracotta
> > > > > > > > > http://twitter.com/alexsnaps
> > > > > > > > > http://www.linkedin.com/in/alexsnaps
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > hibernate-dev mailing list
> > > > > > > > > hibernate-dev at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > 
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > 
> > > 
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>