On 26 août 09, at 22:08, Hardy Ferentschik wrote: Remember, Hibernate Search's mission is to make full-text search as easy to use as possible to increase the overall technology adoption. There are several advantages to the DSL API listed below, but let's compare my example and the Lucene equivalent and see if you can still claim the API to be useless with a straight face. SealedQueryBuilder qb = searchFactory.withEntityAnalyzer(Address.class); Query luceneQuery = qb.must(Occurs.MUST) .add( qb.boolean(Occurs.Should) .add( qb.term("city", "Atlanta").boostedTo(4).createQuery() ) .add( qb.term("address1", "Peachtree").fuzzy().threshold(. 7).createQuery() ) ) .add( qb.from("movingDate", "200604").to("201201").exclusive().createQuery() ) .createQuery(); vs BooleanQuery luceneQuery = new BooleanQuery(); BooleanQuery addressLocationQuery = new BooleanQuery(); Query city = new TermQuery( new Term("city", "Atlanta") ); city.setBoost(4f); addressLocationQuery.add(BooleanClause.Occur.Should, city); Query address1 = new FuzzyQuery( new Term("address1", "Peachtree"), . 7 ); addressLocationQuery.add(BooleanClause.Occur.Should, address1); luceneQuery.add(BooleanClause.Occur.Must, addressLocationQuery); Query range = new RangeQuery( new Term("movingDate", "200604"), new Term("movingDate", "201201", false); luceneQuery.add(BooleanClause.Occur.Must, range); Advantages: - the query is readable and understandable even to new Lucene users. BTW the example is a quite simple one, it does not involve filter, search in multiple fields, query negation etc. - I have normalized some operations that require knowledge of the lucene query hierarchy (eg. ConstantScoreQuery, ConstantScorePrefixQuery, ConstrantScoreRangeQuery or PrefixQuery vs WildcardQuery) - the API shows available options right away using IDE auto- completion, not by looking at the Query hierarchy and its implementations - the API does take the analyzer into account which means that I can take my input and use it without thinking much about the underlying analyzer used at indexing time. In the example, my plain Lucene rewrite of the query will very likely fail because "Atlanta" and "Peachtree" should really be "atlanta" and "peachtree". In the API, we have the analyzer and can take that into account. Likewise for synonyms, phonetic approximation etc. Even worse, trying to search a user query containing several words in different fields is quite difficult in plain Lucene. In the new API it could look like: String search = "harry potter"; SealedQueryBuilder qb = searchFactory.withEntityAnalyzer(Book.class); Query luceneQuery = qb.searchInMultipleFields() .onField("title").boostedTo(4) .onField("title_ngram") .onField("description") .onField("description_ngram").boostedTo(.25) .forWords(search); vs String search = "harry potter"; Analyzer analyzer = searchFactory.getAnalyzer(Book.class); Map<String,Float> boostPerField = new HashMap<String,Float>(2); // boost factors boostPerField.put( "title", (float) 4); boostPerField.put( "title_ngram", (float) 1); boostPerField.put( "description", (float) 1); boostPerField.put( "description_ngram", (float) .25); BooleanQuery luceneQuery = new BooleanQuery(); for ( Map.Entry<String, Float> entry : boostPerField.entrySet() ) { final String fieldName = entry.getKey(); final Float boost = entry.getValue(); List<String> terms = new ArrayList<String>(); try { Reader reader = new StringReader(search); TokenStream stream = analyzer.tokenStream( fieldName, reader); Token token = new Token(); token = stream.next(token); while (token != null) { if (token.termLength() != 0) { String term = new String(token.termBuffer(), 0, token.termLength()); terms.add( term ); } token = stream.next(token); } } catch ( IOException e ) { throw new RuntimeException("IO exception while reading String stream??", e); } for (String term : terms) { TermQuery termQuery = new TermQuery( new Term( fieldName, term ) ); termQuery.setBoost( boost ); luceneQuery.add( termQuery, BooleanClause.Occur.SHOULD ); } } Did I make my case?

On Thu, 27 Aug 2009 10:48:42 +0200, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: Yes. I can agree that your code is more readable and it will help building queries. That said, why not suggesting something like this to the Lucene folks directly. I agree on this one with Manik. --Hardy

On 27 Aug 2009, at 13:06, Emmanuel Bernard wrote: I thought this stuff you mentioned made sense: 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? 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 :) -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org

On 27 Aug 2009, at 16:10, Emmanuel Bernard wrote: 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

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&gt;: