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

Manik Surtani manik at jboss.org
Mon Sep 7 12:53:45 EDT 2009


This stuff is looking pretty good.  Some thoughts inline:

On 3 Sep 2009, at 22:36, Emmanuel Bernard wrote:

>
> 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()

rather than must().not(), is it not better to have a single mustNot()  
method?  Where else could you attach a .not()?  If the number of  
places are finite and small, then are we better off combining them?

>
>>
>> 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.

This looks great.

>
>>
>> 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 at 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 <manik at 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
>>>>> manik at jboss.org
>>>>> Lead, Infinispan
>>>>> Lead, JBoss Cache
>>>>> http://www.infinispan.org
>>>>> http://www.jbosscache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>
>>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org








More information about the hibernate-dev mailing list