Re: [hibernate-dev] [HSearch] DSL for Lucene queries (was: Re: [infinispan-dev] Query module new API and configurations)

2009-08-26 Thread Hardy Ferentschik
On Wed, 2009-08-26 at 13:39 +0200, Emmanuel Bernard wrote: > I've been thinking about a DSL to build Lucene queries in the last > day. > What do you think of this proposal? What do you really gain compared to native Lucene queries? If your API achieves exactly the same as what's possible with Luce

Re: [hibernate-dev] [infinispan-dev] Feedback on Infinispan patch

2009-08-26 Thread Łukasz Moreń
Hi, thanks for comments ant tips. I'm improving it.Yes, I was checking with profiler tool and hashcode - even not so heavy - was called often summary took some time. There is one test where multiple threads can read or write from/to different cache instances. However I think would be good to do som

Re: [hibernate-dev] [infinispan-dev] Feedback on Infinispan patch

2009-08-26 Thread Manik Surtani
Hi there - all looks good. Some comments: Summary documentation - is this going to be published on a wiki page or something somewhere? Especially the Infinispan bit? I think people will find this info very useful... CacheKey - if this class is what everything is going to be used in the c

[hibernate-dev] [HSearch] DSL for Lucene queries (was: Re: [infinispan-dev] Query module new API and configurations)

2009-08-26 Thread Emmanuel Bernard
I've been thinking about a DSL to build Lucene queries in the last day. What do you think of this proposal? A few remarks: - it asks the analyzer so that we correctly apply the analyzer on terms - it has a few query factory methods - it contains a few orthogonal operations - I am not quite

Re: [hibernate-dev] Package renaming

2009-08-26 Thread Emmanuel Bernard
Hi I think it would be slightly better to do the package renaming. I can't find any downside to it. The diff is too small to be useful to developers anyway. On 26 août 09, at 10:25, Hardy Ferentschik wrote: > Hi, > > Regarding HV-185 - I checked the class names and there wouldn't be > any con