[hibernate-dev] Hibernate OGM

Thu May 12 13:49:22 EDT 2011

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

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
>
>