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
Even if it's fluent it's not (yet) intuitive to me which methods I
Query luceneQuery =
I guess there is a typo? As "must(MUST)" is a bit confusing to me.
.Must( qb.otherQuery(...).. )
.Should( qb.secondQuery(..).. )
.add( qb.from().to() )
.add( ... )
or even overloading
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"),
Or even qb.on("city").matches("atlanta")
which could also be used to unify range queries and multi term queries
qb.rangeQuery could be either
rangeQuery("field", "fromX", "toY")
so why are you choosing ("field","from").to("to") ?
are better, I've move to range and if we decide on is better, I will
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
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 :)
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
>> 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
>> a reasonable Analyzer for each field. Most users on the forum are in
>> trouble because they select the wrong analyzer/ forget to use one
>> 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.
>> 2009/8/27 Manik Surtani <manik(a)jboss.org>:
>>> On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote:
>>> .overridesForField(String field, Analyzer)
>>> .overridesForField(String field, Analyzer)
>>> .build() //sucky name
>>> Perhaps rename the static factory methods to something like:
>>> and QueryBuilder instances have overrideAnalyzerForField(String,
>>> 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
>>> making it immutable.
>>> Also the overridesForField methods would pollute the API when
>>> it's time
>>> 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
>>> it, we can contribute it back even though I am not necessarily a
>>> huge fan
>>> Not it doesn't have to be either ASL or even hosted at Apache. I
>>> I am suggesting is perhaps even a separate project -
>>> something - which plain-old-Lucene users could use as well.
>>> 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.
>>> spinning out will be a PITA. Lucene should be the only
>>> dependencies of
>>> Manik Surtani
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> infinispan-dev mailing list