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.
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.