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

On 27 août 09, at 13:07, Manik Surtani wrote: > Very elegant. I'm generally a big fan of 'builder' patterns like > this, but this really isn't a DSL, is it? :) When you first > mentioned a DSL I had visions of defining a new grammar and an > ANTLR parser, etc. But that is overkill. This is called an internal DSL, ie you use Java as the language, not some external representation. > > This approach certainly works, and will almost certainly perform > better too. One question: for the sake of brevity, why > SealedQueryBuilder instead of QueryBuilder ? :) The name is not right yet There are two things: - the query builder that lets you define the analyzer - the query builder that has an analyzer assigned and lets you build query What name is best for each of them.

queryBuilder.withAnalyzer(Analyzer) queryBuilder.withEntityAnalyzer(Class<?>) queryBuilder.basedOnEntityAnalyzer(Class<?>) .overridesForField(String field, Analyzer) .overridesForField(String field, Analyzer) .build() //sucky name

> > Also, I still think that if this is a generic helper factory that > helps you build Lucene queries - and has no knowledge of how and > where the query is used (why should it?) - then this should be > something people can use outside of HS or Infinispan. E.g., > directly with Lucene. As of today this code is technically pure Lucene but to be honest the idea of passing an analyzer multiplexer (like the one we receive from searchFactory.getAnalyzer<Class<?>)) is not wildly spread in Lucene and potentially cumbersome wo the declarative approach of HSearch. The second problem is that some potential improvements will require inner knowledge of HSearch: - object parameters (and not string params) do require to know the FieldBridge of the property. This is a pure HSearch notion. - "property literal" like JPA is introducing could be added to replace the String-based field approach in some situations. Though I don't think that it would be a perfect fit. - spell checker (the old idea we had) 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.