[hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
Emmanuel Bernard
emmanuel at hibernate.org
Thu Sep 3 17:36:51 EDT 2009
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 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
>>>>
>>
>>
More information about the hibernate-dev
mailing list