Unintentionally left the ML out.

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

On Wednesday 11 May 2011 at 16:50, Sanne Grinovero wrote: > 2011/5/11 Alex Snaps <alex.snaps(a)gmail.com&gt;: > > 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(a)gmail.com&gt;: > > > > 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/d0fcbffed4c4bcc2aa5208c... > > > > > > > > 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(a)gmail.com&gt; > > > > Senior Software Engineer - Terracotta > > > > http://twitter.com/alexsnaps > > > > http://www.linkedin.com/in/alexsnaps > > > > > > > > _______________________________________________ > > > > hibernate-dev mailing list > > > > hibernate-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

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(a)gmail.com&gt;: >> 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(a)gmail.com&gt;: >>>> 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(a)gmail.com&gt;: >>>>>> 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/d0fcbffed4c4bcc2aa5208c... >>>>>> >>>>>> 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(a)gmail.com&gt; >>>>>> Senior Software Engineer - Terracotta >>>>>> http://twitter.com/alexsnaps >>>>>> http://www.linkedin.com/in/alexsnaps >>>>>> >>>>>> _______________________________________________ >>>>>> hibernate-dev mailing list >>>>>> hibernate-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> >> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

> 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(a)hibernate.org&gt; > > > > 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(a)gmail.com&gt;: > > > > 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(a)gmail.com&gt;: > > > > > > 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(a)gmail.com&gt;: > > > > > > > > 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/d0fcbffed4c4bcc2aa5208c... > > > > > > > > > > > > > > > > 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(a)gmail.com&gt; > > > > > > > > Senior Software Engineer - Terracotta > > > > > > > > http://twitter.com/alexsnaps > > > > > > > > http://www.linkedin.com/in/alexsnaps > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > hibernate-dev mailing list > > > > > > > > hibernate-dev(a)lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev