[infinispan-dev] [hibernate-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)

[Emmanuel Bernard]

>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090827/a0ca7281/attachment-0002.html