On 28 août 09, at 07:54, Sanne Grinovero wrote: > Sure I like it! I'm in the swamp of old mails, so I give you my first > impression only: > Even if it's fluent it's not (yet) intuitive to me which methods I should > call; > > Query luceneQuery = > qb.must(Occurs.MUST) >   .add( >       qb.boolean(Occurs.Should) >           .add( qb.term("city", "Atlanta").boostedTo(4).createQuery() ) >           .add( qb.term("address1", "Peachtree").fuzzy().createQuery() ) >   ) >   .add( >       qb.from("movingDate", > "200604").to("201201").exclusive().createQuery() >   ) >   .createQuery(); > > I guess there is a typo? As "must(MUST)" is a bit confusing to me. yep typo. > why not > > qb.booleanQuery() >  .Must( qb.otherQuery(...).. ) >  .Should( qb.secondQuery(..).. ) >  .build(); good idea, .must()  .add( qb.from().to() )  .add( ... ) .must().not() .should() > > and > qb.termQuery("city", "Atlanta").boostedTo(4).createQuery()) > or even overloading > qb.termQuery("city", "Atlanta").createQuery()) > with > qb.termQuery("city", "Atlanta", 4f).createQuery()) > is not as readable as "boostedTo" method but more immediate; > intelligent IDEs should propose the options to devs while typing, even > guessing the parameter name and making it's meaning self-evident. No I find it hard and confusing even in IntelliJ IDEA to use overloaded methods and a set of parameters. The idea behing boostedTo() is to mimick named parameters. Actually ideally we would want  term().on("city").matches("Atlanta"), WDYT? Or even qb.on("city").matches("atlanta")

which could also be used to unify range queries and multi term queries qb.on("date").from("2009").to("2010")

qb.on("a").on("b").matches("word")

> > qb.rangeQuery could be either >  rangeQuery("field", "fromX", "toY") > or >  rangeQuery("field").from("x").to("y") > so why are you choosing ("field","from").to("to") ? I think range("field").from("x").to("y") or on("field").from("x").to("y") are better, I've move to range and if we decide on is better, I will move.

> > Thinking about the RangeQuery on dates, it would be cool to accept any > type for which we have Bridges, like accepting Date type or even a > user-defined FieldBridge together with an Object. That would be cool but realistically we need to accept Object unless somehow we can convey the "expected" type(s) of a field bridge using generics or something. SOmebody has an idea on how the API would look like? probably something like <T> on(String field, Class<T>) ... on("field", Date.class).from(new Date()).

> > I like the Analyzer choices, it would be very cool if we could by > default guess the correct one from the searched-for entity types. Define guessing. Guessing the targeted entity? How?

> > We could even consider a Query-By-Example query builder, reading > indexed fields from an instance of an indexed type, or something like > HSEARCH-119 proposal (for termvectors similatory). +1 but let's start (not so) modest :) > > cheers, > Sanne > > 2009/8/28 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> >> Hey Sanne, >> What do you think of the PAI proposal itself? >> Like it? See improvements? >> >> On 28 août 09, at 10:37, Sanne Grinovero wrote: >> >>> I've nothing against a separate maven module, still Hibernate Search >>> already has lots of "goodies" to work with Lucene which are not >>> necessarily linked to Hibernate (e.g. Analyzer definition helpers, >>> pojo mapping through annotations, enhanced filtering, IndexReader >>> pooling, nice Infinispan Directory...) so this new query builder is >>> not much different. Just a thought. >>> >>> So even if Emmanuel has shown this builder to be useful even with this >>> limited features, it could become even more useful when strongly >>> combined with the other features; 2 come to mind, may be more later: >>> >>> A) adding filters to the builders; I don't think it would be easy to >>> have named filters without the full Search package >>> >>> B) Letting the users forget about the Analyzer matches complexity >>> (optionally), as by using the mapping information we could default to >>> a reasonable Analyzer for each field. Most users on the forum are in >>> trouble because they select the wrong analyzer/ forget to use one when >>> building the F.T.Query. >>> >>> IMHO these are good reasons to couple it to the rest of the code; >>> Maybe it would be possible in future to have Hibernate optional. >>> >>> Sanne >>> >>> >>> 2009/8/27 Manik Surtani <manik(a)jboss.org&gt;: >>>> >>>> On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote: >>>> >>>> >>>> queryBuilder.withAnalyzer(Analyzer) >>>> queryBuilder.withEntityAnalyzer(Class<?>) >>>> queryBuilder.basedOnEntityAnalyzer(Class<?>) >>>>                   .overridesForField(String field, Analyzer) >>>>                   .overridesForField(String field, Analyzer) >>>>                   .build() //sucky name >>>> >>>> Perhaps rename the static factory methods to something like: >>>> QueryBuilder.getQueryBuilder(Analyzer) >>>> QueryBuilder.getQueryBuilder(Class<?>) >>>> and QueryBuilder instances have overrideAnalyzerForField(String, >>>> Analyzer). >>>>  Why do you need the build() method at the end? >>>> >>>> if you do that, all of the sudden, a QB can change it's analyzer on the >>>> fly >>>> making it immutable. >>>> Also the overridesForField methods would pollute the API when it's time >>>> to >>>> create a query. >>>> One of the advantages of a fluent API in a strongly typed environment >>>> is >>>> that we can hide methods that are meaningless in a given context. >>>> >>>> That been said, if the API ends up being pure Lucene and once we >>>> stabilize >>>> it, we can contribute it back even though I am not necessarily a huge >>>> fan >>>> of >>>> ASL. >>>> >>>> Not it doesn't have to be either ASL or even hosted at Apache.  I guess >>>> what >>>> I am suggesting is perhaps even a separate project - LuceneQueryBuilder >>>> or >>>> something  - which plain-old-Lucene users could use as well.  Doesn't >>>> matter >>>> where it's hosted or what the license is - as long as its ASL or LGPL >>>> :) >>>> >>>> Let's start it under the Hibernate Search umbrella due to potential >>>> synergies and spin it out if needed. >>>> >>>> Ok.  Just make sure we use a different maven module or something so >>>> that >>>> there are no dependencies on the rest of HS or Hibernate.  Otherwise >>>> spinning out will be a PITA.  Lucene should be the only dependencies of >>>> this >>>> code. >>>> Cheers >>>> -- >>>> Manik Surtani >>>> manik(a)jboss.org >>>> Lead, Infinispan >>>> Lead, JBoss Cache >>>> http://www.infinispan.org >>>> http://www.jbosscache.org >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >> >>

I don't see how people would nicely have access to the right bridge implementation

I was expecting to guess the right type from the property name / field name.

On 8 sept. 09, at 14:51, Sanne Grinovero wrote: > 2009/9/3 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> >> I don't see how people would nicely have access to the right bridge >> implementation >> > > I did't mean to give a reference the the right bridge, just that if people > were defining a custom bridge, they may use it. > If they don't specify  bridge, we select the appropriate one basing on the > type > provided. > > By selecting I mean using the ones in "builtInBridges" map in > BridgeFactory; > we could use the map by reading the type at runtime or overload the > method: > > <T> void from(T lowerBoundary, StringBridge<T> bridge){ > .. > } > void from(int lowerBoundary){ >  from( lowerBoundary, BridgeFactory.INTEGER); > } > void from(boolean lowerBoundary){ >  from( lowerBoundary, BridgeFactory.BOOLEAN); > } > > It's a bit verbose for us, but should be good to use.

On 28 août 09, at 07:54, Sanne Grinovero wrote: > Sure I like it! I'm in the swamp of old mails, so I give you my first > impression only: > Even if it's fluent it's not (yet) intuitive to me which methods I > should call; > > Query luceneQuery = > qb.must(Occurs.MUST) > .add( > qb.boolean(Occurs.Should) > .add( qb.term("city", > "Atlanta").boostedTo(4).createQuery() ) > .add( qb.term("address1", > "Peachtree").fuzzy().createQuery() ) > ) > .add( > qb.from("movingDate", > "200604").to("201201").exclusive().createQuery() > ) > .createQuery(); > > I guess there is a typo? As "must(MUST)" is a bit confusing to me. yep typo. > why not > > qb.booleanQuery() > .Must( qb.otherQuery(...).. ) > .Should( qb.secondQuery(..).. ) > .build(); good idea, .must() .add( qb.from().to() ) .add( ... ) .must().not() .should()

> > and > qb.termQuery("city", "Atlanta").boostedTo(4).createQuery()) > or even overloading > qb.termQuery("city", "Atlanta").createQuery()) > with > qb.termQuery("city", "Atlanta", 4f).createQuery()) > is not as readable as "boostedTo" method but more immediate; > intelligent IDEs should propose the options to devs while typing, > even > guessing the parameter name and making it's meaning self-evident. No I find it hard and confusing even in IntelliJ IDEA to use overloaded methods and a set of parameters. The idea behing boostedTo() is to mimick named parameters. Actually ideally we would want term().on("city").matches("Atlanta"), WDYT? Or even qb.on("city").matches("atlanta") which could also be used to unify range queries and multi term queries qb.on("date").from("2009").to("2010") qb.on("a").on("b").matches("word") > > qb.rangeQuery could be either > rangeQuery("field", "fromX", "toY") > or > rangeQuery("field").from("x").to("y") > so why are you choosing ("field","from").to("to") ? I think range("field").from("x").to("y") or on("field").from("x").to("y") are better, I've move to range and if we decide on is better, I will move.

> > Thinking about the RangeQuery on dates, it would be cool to accept > any > type for which we have Bridges, like accepting Date type or even a > user-defined FieldBridge together with an Object. That would be cool but realistically we need to accept Object unless somehow we can convey the "expected" type(s) of a field bridge using generics or something. SOmebody has an idea on how the API would look like? probably something like <T> on(String field, Class<T>) ... on("field", Date.class).from(new Date()). > > I like the Analyzer choices, it would be very cool if we could by > default guess the correct one from the searched-for entity types. Define guessing. Guessing the targeted entity? How? > > We could even consider a Query-By-Example query builder, reading > indexed fields from an instance of an indexed type, or something like > HSEARCH-119 proposal (for termvectors similatory). +1 but let's start (not so) modest :) > > cheers, > Sanne > > 2009/8/28 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: >> Hey Sanne, >> What do you think of the PAI proposal itself? >> Like it? See improvements? >> >> On 28 août 09, at 10:37, Sanne Grinovero wrote: >> >>> I've nothing against a separate maven module, still Hibernate >>> Search >>> already has lots of "goodies" to work with Lucene which are not >>> necessarily linked to Hibernate (e.g. Analyzer definition helpers, >>> pojo mapping through annotations, enhanced filtering, IndexReader >>> pooling, nice Infinispan Directory...) so this new query builder is >>> not much different. Just a thought. >>> >>> So even if Emmanuel has shown this builder to be useful even with >>> this >>> limited features, it could become even more useful when strongly >>> combined with the other features; 2 come to mind, may be more >>> later: >>> >>> A) adding filters to the builders; I don't think it would be easy >>> to >>> have named filters without the full Search package >>> >>> B) Letting the users forget about the Analyzer matches complexity >>> (optionally), as by using the mapping information we could default >>> to >>> a reasonable Analyzer for each field. Most users on the forum are >>> in >>> trouble because they select the wrong analyzer/ forget to use one >>> when >>> building the F.T.Query. >>> >>> IMHO these are good reasons to couple it to the rest of the code; >>> Maybe it would be possible in future to have Hibernate optional. >>> >>> Sanne >>> >>> >>> 2009/8/27 Manik Surtani <manik(a)jboss.org&gt;: >>>> >>>> On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote: >>>> >>>> >>>> queryBuilder.withAnalyzer(Analyzer) >>>> queryBuilder.withEntityAnalyzer(Class<?>) >>>> queryBuilder.basedOnEntityAnalyzer(Class<?>) >>>> .overridesForField(String field, Analyzer) >>>> .overridesForField(String field, Analyzer) >>>> .build() //sucky name >>>> >>>> Perhaps rename the static factory methods to something like: >>>> QueryBuilder.getQueryBuilder(Analyzer) >>>> QueryBuilder.getQueryBuilder(Class<?>) >>>> and QueryBuilder instances have overrideAnalyzerForField(String, >>>> Analyzer). >>>> Why do you need the build() method at the end? >>>> >>>> if you do that, all of the sudden, a QB can change it's analyzer >>>> on the >>>> fly >>>> making it immutable. >>>> Also the overridesForField methods would pollute the API when >>>> it's time >>>> to >>>> create a query. >>>> One of the advantages of a fluent API in a strongly typed >>>> environment is >>>> that we can hide methods that are meaningless in a given context. >>>> >>>> That been said, if the API ends up being pure Lucene and once we >>>> stabilize >>>> it, we can contribute it back even though I am not necessarily a >>>> huge fan >>>> of >>>> ASL. >>>> >>>> Not it doesn't have to be either ASL or even hosted at Apache. I >>>> guess >>>> what >>>> I am suggesting is perhaps even a separate project - >>>> LuceneQueryBuilder >>>> or >>>> something - which plain-old-Lucene users could use as well. >>>> Doesn't >>>> matter >>>> where it's hosted or what the license is - as long as its ASL or >>>> LGPL :) >>>> >>>> Let's start it under the Hibernate Search umbrella due to >>>> potential >>>> synergies and spin it out if needed. >>>> >>>> Ok. Just make sure we use a different maven module or something >>>> so that >>>> there are no dependencies on the rest of HS or Hibernate. >>>> Otherwise >>>> spinning out will be a PITA. Lucene should be the only >>>> dependencies of >>>> this >>>> code. >>>> Cheers >>>> -- >>>> Manik Surtani >>>> manik(a)jboss.org >>>> Lead, Infinispan >>>> Lead, JBoss Cache >>>> http://www.infinispan.org >>>> http://www.jbosscache.org >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >> >> _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev