[hibernate-dev] Lucene 3.1 : we're ready as well, but should have have it in 3.4?

Sanne Grinovero sanne at hibernate.org
Sun Apr 3 18:08:44 EDT 2011


Hello,
I'm sure you all have heard all the noise about the Lucene 3.1
release, it has indeed some interesting changes [1]; it's almost
drop-in compatible with Lucene 3.0.x but providing some interesting
performance improvements and a huge amount of bugfixes.
Some of these fixes are memory leaks, index corruption, failing to
properly update index contents, returning stale IndexReaders.. a long
list of improvements that we would like to provide to our users as
well.

In practice, I already did all the work:
https://github.com/Sanne/hibernate-search/commits/HSEARCH-705

Just one concern: we're currently in CR1 phase.
Shall we get this in, or postpone for 3.5 ?

Some details:

If someone was to try to use current Hibernate Search with Lucene 3.1:
 * Faceting won't work
 * RAMDirectory won't work
There are many more changes in the tests, but this is of no interest to users.

In the opposite case, if we upgrade and people wished to stay on
Lucene <3.1, it won't work:
we need to use some of the new APIs, especially TotalHitCountCollector
to count for matches is now a requirement when queryResultSize() is
used, but this class didn't exist in Lucene 3.0.x.

The Infinispan Lucene Directory works fine with all versions of Lucene
2.9.x, 3.0.x, 3.1.0, so this dependency is not going to block this.

Opinions? if there's time for it, I'd propose a CR2 to get this update
in, would be nice to have HSEARCH-679 as well as Tom contributed a
test for it.

Sanne

[1] - http://lucene.apache.org/#31+March+2011+-+Lucene+Core+3.1+and+Solr+3.1+Available



More information about the hibernate-dev mailing list