Re: [hibernate-dev] [infinispan-dev] [HSearch] DSL for Lucene queries (was: Re: Query module new API and configurations)
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(a)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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev