- Hibernate Search 3.2.0.Beta1
- Hibernate Search 3.1.0.GA
- Hibernate Search 3.1.0.CR1
- Hibernate Search 3.1.0.Beta2
- Hibernate Search 3.1.0.Beta1
- Hibernate Search 3.0.0.GA
- Hibernate Search 3.0.0.CR1
- Hibernate Search 3.0.0.Beta4
- Hibernate Search 3.0.0.Beta2
Hibernate Search 3.2.0.Beta1
Discriminator interface changes
- The getAnanyzerDefinitionName method name in org.hibernate.search.analyzer.Discriminator contained a typo and is now called getAnalyzerDefinitionName.
IndexWriter tuning configuration changes
- Until previous version any configuration option set as indexwriter.transaction.<parameter_name> would also affect the batch version of it, unless indexwriter.batch.<parameter_name> was explicitly set. This was leading to confusion and now to set a batch parameter you have to explicitly set it.
Hibernate Search 3.1.0.GA
Make sure to review the migration guides from the 3.1.x intermediate releases.
Hibernate Search 3.1.0.CR1
- As part of this release we removed calls to deprecated methods and classes in the Lucene 2.4 API. This includes the usage of the deprecated Hits class. This implies that projected Lucene scored won't be normalized anymore.
Hibernate Search 3.1.0.Beta2
- Most APIs have been properly generified. For example, They now accept Class<?> rather than the raw type. You might need to recompile your code and fix a few warnings.
- ReaderProvider has a new method destroy()
- This version makes use of Lucene 2.4.0.
- The Filter definition declaration has changed a bit. Use @FullTextFilterDef.cache now receives FilterCacheModeType enums and is the only cache related configuration. It defaults to cache filter instances and BitSet results.
Hibernate Search 3.1.0.Beta1
- Hibernate Search 3.1 depends on Hibernate Core 3.3, and is integrated with Hibernate Annotations 3.4
- The logging system has moved to slf4j
- The Lucene version must be 2.3 and above
- Optimizations features involving Lucene tuning are now under hibernate.search.[default|<indexname>].indexwriter.[transaction|batch]
- FullTextQuery.BOOST is now deprecated, it always returned 1 and had no concrete usage
- Search.createFullTextSession and Search.createFullTextEntityManager are deprecated and replaced by Search.getFullTextSession and Search.getFullTextEntityManager
- hibernate.search.worker.batch_size is deprecated in favor to the fullTextSession.flushToIndexes();
- Calling fullTextSession.index / purge: raises an exception if the entity is not indexable rather than the previous noop.
- If you implement org.hibernate.search.bridge.FieldBridge or org.hibernate.search.bridge.TwoWayFieldBridge, the method set() has evolved to the following signature void set(String name, Object value, Document document, LuceneOptions luceneOptions)
Hibernate Search 3.0.0.GA
- query.setIndexProjection has been removed (after deprecation), the replaced method is query.setProjection
Hibernate Search 3.0.0.CR1
- DirectoryProvider has a new method start()
- @Text, @Keyword and @Unstored have been removed
Hibernate Search 3.0.0.Beta4
- @Text, @Keyword etc have been deprecated for a while, they will be removed in the next release.
- fullTextQuery.setIndexProjection() has been renamed fullTextQuery.setProjection()
- The default reader strategy is now shared (this should not affect the compatibility though)
- ContextHelper.getSearchFactory is deprecated, prefer fullTextSession.getSearchFactory();
- searchFactory.getDirectoryProvider(Class) is now searchFactory.getDirectoryProviders(Class)
- Lucene Core 2.2 is now used: your index structure will be automatically migrated by Lucene.
Hibernate Search 3.0.0.Beta2
- All org.hibernate.search.query.FullTextQueryImpl casting should be replaced by org.hibernate.search.FullTextQuery casting
- resultSize() has been renamed getResultSize()
- Queries restricting to one entity now use one SQL query rather than depending on @BatchSize() when list() is used, the major impact is that it's going to be faster
- Query query = fullTextSession.createFullTextQuery(luceneQuery, book.class);
- The build phase for Lucene Documents is now done in the beforeCompletion phase of a transaction, making the process insensible to LazyInitializationException. There should be no impact to users that did not hit the bug.