Re: [hibernate-dev] [infinispan-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.