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._______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
