answers and ideas inline:
2009/9/3 Emmanuel Bernard <emmanuel(a)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(a)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(a)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(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
>>>>
>>
>>