[hibernate-dev] Search: to follow or not to follow latest Lucene index format
Sanne Grinovero
sanne at hibernate.org
Fri Jul 8 13:40:10 EDT 2011
So the testsuite is using an helper method
"org.hibernate.search.test.SearchTestCase.getTargetLuceneVersion()"
for all those cases in which the unfriendly Lucene API demands a version.
The test method is currently returning this constant:
Version.LUCENE_31
The ConfigContext is using a default of Version.LUCENE_30 if the user
doesn't specify any version in the configuration.
..and I recently updated the Lucene dependency to 3.3, without
changing these values.
Now if we really want to keep them in sync, we could use
Version.LUCENE_CURRENT;
but this is deprecated, not because it's going to be removed but
because there are implications in using it, so it's discouraged.
It's also nice to be able to verify compatibility of Search's use of
Lucene when using a backwards compatible index format.
I think we're not tracking the latest version of Lucene with this
flag, because we wanted to make sure we where backwards compatible.
Given we're now having the option to break backwards compatibility,
should we start tracking the latest version of Lucene, and log a
warning if the configuration value is not set?
As the Lucene developers suggest, we should recommend coding this
value in the configuration.
Also because Hibernate Search now seems to work equally well with all
Lucene 3.0.x, 3.1.x and 3.3.x, we should either consider only the
latest supported, or test for the others too:
worth having an environment parameter to be able to run the testsuite
with older Lucene versions, or run it in mixed environments of newer
Lucene versions but configured as older versions?
Cheers,
Sanne
More information about the hibernate-dev
mailing list