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 <ma...@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 > ma...@jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-...@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
