Re: [hibernate-dev] Hibernate OGM
On Thursday 12 May 2011 at 19:49, Sanne Grinovero wrote: 2011/5/12 Nicolas Helleringer : > > 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 > > > > > > Let me summarize, > > > GridMap is the equivalent of Cache, right? > > > I agree that Map is not the right representation, plus > > > Map> 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 : > > > > > 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 : > > > > > > > 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 > > > > > > > >
Re: [hibernate-dev] Hibernate OGM
On Thursday 12 May 2011 at 17:17, Emmanuel Bernard wrote: I've significantly improved the GridDialect in my quest to use Atomic Maps for entity and associations. Unfortunately the change is not ready to be shared yet. I hope to get that out next week Entity are using atomic maps but not associations yet. Seems like a big enough change. I'll wait for that to become available before sharing anything further myself then... > Also, I've see you've used merge to sync your work and the main tree. We have > a linear tree policy, so use rebase instead of merge. I think this mainly due to me rebasing before rearranging & squashing my changes. Not so much at ease with git yet... But I'll find a way to clean that all up nicely when getting to a pull request. > > On 11 mai 2011, at 15:12, Alex Snaps wrote: > > > 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 > > 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
Re: [hibernate-dev] Hibernate OGM
yes git cherry-pick will be your friend to clean the mess On 13 mai 2011, at 16:16, Alex Snaps wrote: > On Thursday 12 May 2011 at 17:17, Emmanuel Bernard wrote: > I've significantly improved the GridDialect in my quest to use Atomic Maps > for entity and associations. Unfortunately the change is not ready to be > shared yet. I hope to get that out next week Entity are using atomic maps but > not associations yet. > Seems like a big enough change. I'll wait for that to become available before > sharing anything further myself then... > >> Also, I've see you've used merge to sync your work and the main tree. We >> have a linear tree policy, so use rebase instead of merge. > I think this mainly due to me rebasing before rearranging & squashing my > changes. Not so much at ease with git yet... > But I'll find a way to clean that all up nicely when getting to a pull > request. > >> >> On 11 mai 2011, at 15:12, Alex Snaps wrote: >> >>> 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 >>> 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
Re: [hibernate-dev] Hibernate OGM
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 > Let me summarize, > GridMap is the equivalent of Cache, right? > I agree that Map is not the right representation, plus > Map> 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 : > >> 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 : > 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 mi
[hibernate-dev] Hibernate 4.0 logging looks too verbose still (suggest changing more info to debug/trace)
Hi, The following Hibernate log output is from running the AS 7.0 integration testsuite (with Hibernate 4.0.0.Alpha3) http://pastie.org/1899179 I think some of the warnings might be telling me that we have something wrong in the AS7/Hibernate integration. For example "23:43:42,001 WARN [org.hibernate.ejb.AbstractEntityManagerImpl] (RMI TCP Connection(2)-127.0.0.1) HHH00326:Cannot join transaction: do not override hibernate.transaction.factory_class". If so, we should fix the problem. I think it would be in the spirit of our logging guideline http://community.jboss.org/wiki/HowtologinJBossprojects, to move some of the (non-critical) INFO messages to DEBUG or TRACE. No one has disagreed about this in the past and many messages have already changed. I wanted to see if we agree that more INFO messages should be changed to DEBUG/TRACE. For example, I think that we should use debug/trace level for indicating when a connection is obtained/released (since that is a normal operation that means that stuff is working). Scott ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
