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

[Sanne Grinovero]

I've nothing against a separate maven module, still Hibernate Search
already has lots of "goodies" to work with Lucene which are not
necessarily linked to Hibernate (e.g. Analyzer definition helpers,
pojo mapping through annotations, enhanced filtering, IndexReader
pooling, nice Infinispan Directory...) so this new query builder is
not much different. Just a thought.

So even if Emmanuel has shown this builder to be useful even with this
limited features, it could become even more useful when strongly
combined with the other features; 2 come to mind, may be more later:

A) adding filters to the builders; I don't think it would be easy to
have named filters without the full Search package

B) Letting the users forget about the Analyzer matches complexity
(optionally), as by using the mapping information we could default to
a reasonable Analyzer for each field. Most users on the forum are in
trouble because they select the wrong analyzer/ forget to use one when
building the F.T.Query.

IMHO these are good reasons to couple it to the rest of the code;
Maybe it would be possible in future to have Hibernate optional.

Sanne


2009/8/27 Manik Surtani <manik at jboss.org>:
>
> On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote:
>
>
> 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.
>
> Ok.  Just make sure we use a different maven module or something so that
> there are no dependencies on the rest of HS or Hibernate.  Otherwise
> spinning out will be a PITA.  Lucene should be the only dependencies of this
> code.
> Cheers
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>