Re: [hibernate-dev] [infinispan-dev] Querying Infinispan -- Help Needed
> I am currently using Hibernate Search 3.1.1 GA Well there's your issue. There was a change between 3.1.0 and 3.1.1. So that's why we've switched the Infinispan dependency back to 3.1.0. A fix has been made in HS trunk, and that works fine. On the Infinispan side, at least we're just waiting on the next release of Hibernate Search so we can update our dependencies. > > On Thu, Nov 19, 2009 at 5:28 PM, Emmanuel Bernard > wrote: > I remember we had that bug, it might be an issue with the version of > HSearch used, which one are you using? Yeah after you mentioned that yesterday while we were chatting I remember this issue. Thanks! > Navin Surtani Intern Infinispan Intern JBoss Cache Searchable ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Querying Infinispan -- Help Needed
> > I am currently using Hibernate Search 3.1.1 GA > > > Well there's your issue. There was a change between 3.1.0 and 3.1.1. So > that's why we've switched the Infinispan dependency back to 3.1.0. > > A fix has been made in HS trunk, and that works fine. On the Infinispan > side, at least we're just waiting on the next release of Hibernate Search so > we can update our dependencies. > Cool... Thanks for bringing this to our notice. Now the issue is solved, I can search through the elements using CacheQuery.getBasicQuery() One last thing, Since I am a novice to this Hibernate & Hibernate Search, Is there any reference documentation to build my knowledge for QueryingInfinispan apart from that wiki page. Or Where should I start my learning to implement querying feature using Infinispan with the help of technical preview provided in that wiki page. Any pointers please. Thanks, Vinoth ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Querying Infinispan -- Help Needed
On 20 Nov 2009, at 10:15, Vinoth wrote: >> I am currently using Hibernate Search 3.1.1 GA > > Well there's your issue. There was a change between 3.1.0 and 3.1.1. > So that's why we've switched the Infinispan dependency back to 3.1.0. > > A fix has been made in HS trunk, and that works fine. On the > Infinispan side, at least we're just waiting on the next release of > Hibernate Search so we can update our dependencies. > > Cool... Thanks for bringing this to our notice. Now the issue is > solved, I can search through the elements using > CacheQuery.getBasicQuery() > > One last thing, > Since I am a novice to this Hibernate & Hibernate Search, > Is there any reference documentation to build my knowledge for > QueryingInfinispan apart from that wiki page. In a word - no :-). However, if you want to get more experience with learning how to query this stuff, I'd say have a look at the Lucene documentation and learn how to use those queries well. I say this because at the end, all you need to do is create a Lucene query and use that to create a CacheQuery instance. The complexity here is creating the Lucene query. The better you know Lucene, the better you can query the Cache :-). > > Or > > Where should I start my learning to implement querying feature using > Infinispan with the help of technical preview provided in that wiki > page. Again, I think the easy thing here is to learn how to use Lucene queries well. Then you know what type of object you have in your Cache and will know how to get what you're looking for quite efficiently. > > Any pointers please. Reckon that helps? > > Thanks, > Vinoth Navin Surtani Intern Infinispan Intern JBoss Cache Searchable ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] Querying Infinispan -- Help Needed
> > One last thing, > Since I am a novice to this Hibernate & Hibernate Search, > Is there any reference documentation to build my knowledge for > QueryingInfinispan apart from that wiki page. > > > In a word - no :-). > > However, if you want to get more experience with learning how to query this > stuff, I'd say have a look at the Lucene documentation and learn how to use > those queries well. I say this because at the end, all you need to do is > create a Lucene query and use that to create a CacheQuery instance. The > complexity here is creating the Lucene query. The better you know Lucene, > the better you can query the Cache :-). > > Or > > Where should I start my learning to implement querying feature using > Infinispan with the help of technical preview provided in that wiki page. > > Again, I think the easy thing here is to learn how to use Lucene queries > well. Then you know what type of object you have in your Cache and will know > how to get what you're looking for quite efficiently. > Yes you are right, even I have started my learning on how to construct lucene queries. I understood the importance of those query constructs in Search Implementation Thanks a ton for your kind help :-) Thanks, Vinoth ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate Search DSL ideas
Heya, I was just thinking last night about a couple of things about the DSL. Mainly, instead of having lots of return types, for example you created a BooleanContext and a Negatable version if the Occur clause was MUST. I was wondering, instead of having separate contexts, is it easier to have one - and then if a user calls a buildQuery() without sufficient information to actually build one we throw an exception? I think this is cleaner in some ways because we don't have to create so many different types of class, and we're always returning the same instance. However, the drawback is that by this method we "allow the user to make a mistake" and will be needing to throw exceptions. So here's where the discussion starts - what are pros/cons of each system and which wind up being a better one to build? Personally, I think having a single class context is better because 1 - it's simpler to build and 2 - as long as classes are documented properly and exceptions thrown are clear as to what the issue is then we're okay. Ideas? Thoughts? Navin Surtani Intern Infinispan Intern JBoss Cache Searchable ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search DSL ideas
I am very against the idea of runtime failures. That's the whole point of a type safe fluent API. I would rather put the effort on the framework side than on the developer side. A string query language or a dynamic language is better if you are not bothered with helping the developer to write the query. On 20 nov. 2009, at 12:31, Navin Surtani wrote: > Heya, > > I was just thinking last night about a couple of things about the DSL. > > Mainly, instead of having lots of return types, for example you > created a BooleanContext and a Negatable version if the Occur clause > was MUST. I was wondering, instead of having separate contexts, is > it easier to have one - and then if a user calls a buildQuery() > without sufficient information to actually build one we throw an > exception? > > I think this is cleaner in some ways because we don't have to create > so many different types of class, and we're always returning the > same instance. However, the drawback is that by this method we > "allow the user to make a mistake" and will be needing to throw > exceptions. So here's where the discussion starts - what are pros/ > cons of each system and which wind up being a better one to build? > Personally, I think having a single class context is better because > 1 - it's simpler to build and 2 - as long as classes are documented > properly and exceptions thrown are clear as to what the issue is > then we're okay. > > Ideas? Thoughts? > > Navin Surtani > > Intern Infinispan > Intern JBoss Cache Searchable > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Programmatic Mapping patch
On 20 nov. 09, at 15:20, Emmanuel Bernard wrote: > Hi Amin, > I've committed your patch, thanks! > There is still some work and questions remaining but that's a big > coverage improvement. Now on to the doc to get the release out :) > > Here is my raw feedback > > 1. > Interface vs class? > Should we start using interfaces instead of classes, at least for > SearchMapping. That way we could hide the getEntityDescriptor() > method to the users. > I think we need to start using superclasses or super interfaces to > enforce the repeated contracts down to the tree of navigation? > > 2. > Should the methods be on IndexedMapping not EntityMapping? > - fullTextFilterDef > - analyzerDiscriminator > - similarity > Question to Hardy and Sanne, do these concepts make sense on a non > @indexed element? I can't remember how the parser behaves. > > I think these methods should be onn IndexedMapping rather than > EntityMapping > - boost > - providedId > > The problem with this approach is that we would need to > differentiate PropertyMapping and IndexedPropertyMapping. I am not > sure this additional complexity is worth the extra help to the > developer. > > 3. > property(String name, ElementType type) should it be replaced with > specific methods like? > .field() => conflict with lucene field > .getter() > > 4. > Is date bridge exclusive to calendar bridge? I think the contract > expresses that today. > > 5. > ContainedInMapping does not contain the necessary upper methods. > > 6. > I've updated the original ProvidedIdTest, Can you push the same > changes to the programmatic version of the test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search DSL ideas
On 20 Nov 2009, at 12:10, Emmanuel Bernard wrote: > I am very against the idea of runtime failures. That's the whole > point of a type safe fluent API. Yeah - understandable, the fewer exceptions thrown the better I guess. > I would rather put the effort on the framework side than on the > developer side. > A string query language or a dynamic language is better if you are > not bothered with helping the developer to write the query. > > On 20 nov. 2009, at 12:31, Navin Surtani wrote: > >> Heya, >> >> I was just thinking last night about a couple of things about the >> DSL. >> >> Mainly, instead of having lots of return types, for example you >> created a BooleanContext and a Negatable version if the Occur >> clause was MUST. I was wondering, instead of having separate >> contexts, is it easier to have one - and then if a user calls a >> buildQuery() without sufficient information to actually build one >> we throw an exception? >> >> I think this is cleaner in some ways because we don't have to >> create so many different types of class, and we're always returning >> the same instance. However, the drawback is that by this method we >> "allow the user to make a mistake" and will be needing to throw >> exceptions. So here's where the discussion starts - what are pros/ >> cons of each system and which wind up being a better one to build? >> Personally, I think having a single class context is better because >> 1 - it's simpler to build and 2 - as long as classes are documented >> properly and exceptions thrown are clear as to what the issue is >> then we're okay. >> >> Ideas? Thoughts? >> >> Navin Surtani >> >> Intern Infinispan >> Intern JBoss Cache Searchable >> Navin Surtani Intern Infinispan Intern JBoss Cache Searchable ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Programmatic Mapping patch
Hi Emmanuel, Thanks. I'm working on the docs at the moment. I've added some of my comments. On Fri, Nov 20, 2009 at 2:21 PM, Emmanuel Bernard wrote: > > On 20 nov. 09, at 15:20, Emmanuel Bernard wrote: > > Hi Amin, > I've committed your patch, thanks! > There is still some work and questions remaining but that's a big coverage > improvement. Now on to the doc to get the release out :) > > Here is my raw feedback > > 1. > Interface vs class? > Should we start using interfaces instead of classes, at least for > SearchMapping. That way we could hide the getEntityDescriptor() method to > the users. > I think we need to start using superclasses or super interfaces to enforce > the repeated contracts down to the tree of navigation? > > makes sense. > > 2. > Should the methods be on IndexedMapping not EntityMapping? > - fullTextFilterDef > - analyzerDiscriminator > - similarity > Question to Hardy and Sanne, do these concepts make sense on a non @indexed > element? I can't remember how the parser behaves. > > > I think these methods should be onn IndexedMapping rather than > EntityMapping > - boost > - providedId > > > The problem with this approach is that we would need to differentiate > PropertyMapping and IndexedPropertyMapping. I am not sure this additional > complexity is worth the extra help to the developer. > > Not sure about indexPropertyMapping, I like the PropertyMapping as it is clear and then I can add other stuff to it. (Long day athe moment so apologies if i don't make sense. > 3. > property(String name, ElementType type) should it be replaced with specific > methods like? > .field() => conflict with lucene field > .getter() > > Again from a user point of view field() makes sense because it is the field that I want represented in lucene. > 4. > Is date bridge exclusive to calendar bridge? I think the contract expresses > that today. > > > 5. > ContainedInMapping does not contain the necessary upper methods. > > I can add these. > 6. > I've updated the original ProvidedIdTest, Can you push the same changes to > the programmatic version of the test. > > > I'll update as well. Thanks. I'll try to get the documentation done as soon as possible. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
