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.
why not
qb.booleanQuery()
.Must( qb.otherQuery(...).. )
.Should( qb.secondQuery(..).. )
.build();
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.
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") ?
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.
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.
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).
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
>>