[hibernate-dev] Hibernate OGM

Thu May 12 11:04:48 EDT 2011

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