Re: [infinispan-dev] [hibernate-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
> 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.
Attachments:
- attachment.html (text/html — 2.6 KB)