[hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
Sanne Grinovero
sanne.grinovero at gmail.com
Thu Sep 3 18:30:53 EDT 2009
answers and ideas inline:
2009/9/3 Emmanuel Bernard <emmanuel at 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 <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