answers and ideas inline: 2009/9/3 Emmanuel Bernard <emman...@hibernate.org>: > > 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")
yes much better > > which could also be used to unify range queries and multi term queries > qb.on("date").from("2009").to("2010") nice > qb.on("a").on("b").matches("word") this is not really fluent, I only understand what you mean because of your comment > >> >> 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. > I agree with your choice >> >> 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 didn't mean that the method signature should be aware of the type, Object is fine; from( Object lowerBoundary ); //automatically finds out the StringBridge from the BridgeFactory from( Object lowerBoundary, StringBridge ); //overrides ths StringBridge selection Even better making StringBridge generic we get typesafety: <T> void from(T lowerBoundary, StringBridge<T> bridge) > >> >> 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? Ha right; I was assuming you were going to select the targeted entity, like with Criteria? > >> >> 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 <emman...@hibernate.org>: >>> >>> 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 <ma...@jboss.org>: >>>>> >>>>> 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 >>>>> ma...@jboss.org >>>>> Lead, Infinispan >>>>> Lead, JBoss Cache >>>>> http://www.infinispan.org >>>>> http://www.jbosscache.org >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> infinispan-...@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> >>> >>> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev