Red Hat



In Relation To Sanne Grinovero

In Relation To Sanne Grinovero

This summer was relatively quiet in terms of releases, but many have been testing and improving the Beta1 release of our Hibernate Search / Elasticsearch integration.

So today we release version 5.6.0.Beta2 with 45 fixes and enhancements!

For a detailed list of all improvements, see this JIRA query.

The day of a Final release gets closer, but highly depends on your feedback. Please keep the feedback coming!

Please let us know of any problem or suggestion by creating an issue on JIRA, by sending an email to the developer’s developer’s mailing lists, or posting on the forums.

We also monitor Stack Overflow; when posting on SO please use the tag hibernate-search.

How to get this release

Everything you need is available on Hibernate Search’s web site.

Get it from Maven Central using the following coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.6.0.Beta2</version>
</dependency>

Downloads from Sourceforge are available as well.

Notes on compatibility

This version is compatible with Apache Lucene versions from 5.3.x to 5.5.x, and with Hibernate ORM versions 5.0.x and 5.1.x.

Compatibility with Hibernate ORM 5.2.x is not a reality yet - we expect to see that materialize in early October. Compatibility with Lucene 6.x is scheduled for Hibernate Search 6.0, which will take longer - probably early 2017.

Finally, the version we used of Elasticsearch for all developing and tests of this version was Elasticsearch v. 2.3.1. We will soon upgrade this to the latest version, and discuss strategies to test against multiple versions.

After over 60 resolved tasks, we’re proud to release Hibernate Search version 5.6.0.Beta1.

The Elasticsearch integration made significant progress, and we believe it to be ready for wider usage.

Progress of the Elasticsearch integration

Improvements since the previous milestone:

MassIndexer

significant better performance as it now uses bulk operations.

Calendar, Dates, numbers and mapping details

several corrections and improvements were made to produce a cleaner schema.

Cluster state

we now wait for a newly started Elasticsearch cluster to be "green" - or optionally "yellow" - before starting to use it.

WildFly modules

a critical bug was resolved, the modules should work fine now.

Many more

for a full list of all 63 improvements, see this JIRA query.

What is missing yet?

Performance testing

we didn’t do much performance testing, it’s probably not as efficient as it could be.

Relax the expected Elasticsearch version

it’s being tested with version 2.3.1 but we have plans to support a wider range of versions.

Explicit refresh requests

we plan to add methods to issue an indexreader refresh request, as the changes pushed to Elasticsearch are not immediately visible by default.

Your Feedback!

we think it’s in pretty good shape, it would be great for more people to try it out and let us know what is missing and how it’s working for you.

Notable differences between using embededd Lucene vs Elasticsearch

Unless you reconfigure Hibernate Search to use an async worker, by default when using the Lucene backend after you commit a transaction the changes to the index are immediately applied and any subsequent search will "see" the changes. On Elasticsearch the default is different: changes received by the cluster are only "visible" to searches after some seconds (1 by default).

You can reconfigure Hibernate Search to force a refresh of indexes after each write operation by using the hibernate.search.default.elasticsearch.refresh_after_write configuration setting.

This setting defaults to false as that’s the recommended setting for optimal performance on Elasticsearch. You might want to set this to true to make it simpler to write unit tests, but you should take care to not rely on the synchronous behaviour for your production code.

Improvements for embedded Lucene users

While working on Elasticsearch, we also applied some performance improvements which apply to users of the traditional Lucene embedded users.

Special thanks to Andrej Golovnin, who contributed several patches to reduce allocation of objects on the hot path and improve overall performance.

How to get this release

Everything you need is available on Hibernate Search’s web site.

Get it from Maven Central using the above coordinates.

Downloads from Sourceforge are available as well.

Feedback

Feedback always welcome!

Please let us know of any problem or suggestion by creating an issue on JIRA, or by sending an email to the developer’s developer’s mailing lists, or posting on the forums.

We also monitor Stack Overflow; when posting on SO please use the tag hibernate-search.

While the team has been busy implementing great new features such as the Elasticsearch integration for the next 5.6 release, some of you provided interesting feedback on our stable release.

The summary of the feedback I heard is that migrating to the new sorting requirements can be confusing, and there were some issues with our Faceting implementation.

Hibernate Search version 5.5.3.Final is available now, fixing the reported issues and improving the error messages around sorting.

The changelog is rather small, so this time I’ll post it verbatim:

  • HSEARCH-1917 - Cannot index null or empty values for faceted fields

  • HSEARCH-2082 - Documentation refers to @SortField when it should be @SortableField

  • HSEARCH-2085 - Typo in hibernate-search-engine logger

  • HSEARCH-2086 - Long and Date range faceting doesn’t honor hasZeroCountsIncluded

  • HSEARCH-2179 - Hanging during shutdown of SyncWorkProcessor

  • HSEARCH-2193 - LuceneBackendQueueTask does not release the Directory lock on update failures

  • HSEARCH-2200 - Typo in log message

  • HSEARCH-2240 - Parallel service lookup might fail to find the service

  • HSEARCH-2199 - Allows the use of CharFilter in the programmatic API of SearchMapping

  • HSEARCH-2084 - Upgrade to WildFly 10.0.0.Final

  • HSEARCH-2089 - Ensure the performance tests do not use the WildFly embedded version of Search

  • HSEARCH-1951 - Improve resulting error message when applying the wrong Sort Type

  • HSEARCH-2090 - Using the wrong header in the distribution/pom.xml

  • HSEARCH-2241 - Clarify deprecation of setFilter() method on FullTextQuery

Spot inefficient sorting operations easily in test suites

While Hibernate Search already would log a warning when forced to perform a query using a sub-optimal sorting strategy, that wasn’t making it very easy to spot mapping or usage mistakes.

Set this property:

    hibernate.search.index_uninverting_allowed = false

and you’ll have your tests fail with an exception rather than log warnings.

This property is not new in this release, but it’s worth reminding as it makes it much easier to validate your migrations from previous versions.

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.5.3.Final</version>
</dependency>
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>5.0.6.Final</version>
</dependency>
<dependency>
   <groupId>org.apache.lucene</groupId>
   <artifactId>lucene-core</artifactId>
   <version>5.3.1</version>
</dependency>

What are we working on?

The Elasticsearch integration is almost feature complete, we expect to be able to release a Beta1 version in some weeks.

How to get this release

Everything you need is available on Hibernate Search’s web site. Download the full distribution from here, or get it from Maven Central using the above coordinates, and don’t hesitate to reach us in our forums or mailing lists.

Having fixed several issues and tasks since the previous milestone, it’s time to publish our third milestone towards Elasticsearch integration: Hibernate Search version 5.6.0.Alpha3 is now available!

Migration from Hibernate Search 5.5.x

Even if you’re not interested in the new Elasticsearch support, you might want to try out this version as it benefits from Apache Lucene 5.5.0.

If you ignore the new features and want to simply use Lucene in embedded mode the migration is easy, and as usual we are maintaining notes regarding relevant API changes in the Migration Guide to Hibernate Search 5.6.

Elasticsearch support progress

  • you can now use the Analyzers from Elasticsearch

  • Multiple operations will now be sent to Elasticsearch as a single batch to improve both performance and consistency

  • Spatial indexing and querying is now feature complete

  • We’ll wait for Elasticsearch to be "green" before attempting to use it at boot

  • Many improvements in the query translation

  • Error capture and reporting was improved

  • the Massindexer is working now, but is not yet using efficient bulk operations

  • the Elasticsearch extensions are now included in the WildFly modules

How to get this release

Everything you need is available on Hibernate Search’s web site.

Get it from Maven Central using the above coordinates.

Downloads from Sourceforge are available as well.

Feedback

Feedback always welcome!

Please let us know of any problem or suggestion by creating an issue on JIRA, or by sending an email to the developer’s developer’s mailing lists, or posting on the forums.

We also monitor Stack Overflow; when posting on SO please use the tag hibernate-search.

Today we’re proud to announce the first Alpha release sporting experimental integration with Elasticsearch!

We also updated to use Apache Lucene 5.5 - the latest stable release of our favourite search engine - as of course we’re not abandoning our traditional users!

What is the Hibernate Search / Elasticsearch integration?

Both Hibernate Search and Elasticsearch can do much more, but for the purpose of explaining this integration at an high level I’ll simplify their definitions as:

Hibernate Search

is a popular extension of the super popular Hibernate ORM framework, which makes it easy to index and query your entities using Apache Lucene.

Elasticsearch

is a very popular REST server which wraps the capabilities of Apache Lucene and makes it easier to scale this service horizontally.

Until today when using Hibernate Search you’d be using Apache Lucene directly, in what we will now call "embedded mode". In this mode a query is executed by the same process of your application, and while indexing happens in background still the overhead of such processing is happening within the same server and within the same JVM process as your Hibernate powered application.

With the Elasticsearch integration, rather than indexing your entities directly by managing the Lucene resources, we will be sending RPCs to an Elasticsearch cluster to achieve a very similar purpose: after all it is also Lucene based, so the feature match is extremely close!

This means that we’re able to transparently map all the current features to this new alternative backend, and by so doing give you more architectural choices at minimum required changes in your applications: the goal is that for most users the differences will be mostly in configuration details.

When using Elasticsearch we will need to send RPCs over the network to run queries and index updates, but on the other hand you benefit from Microservices - style decoupling and all the nice features that Elasticsearch can provide in terms of running and managing an horizontally scalable cluster.

In a nutshell…​

Elasticsearch will manage the index for you, Hibernate ORM will manage your objects and the transactions, Hibernate Search will transparently keep Elasticsearch synchronized to your database transactions and let you query your Domain Model returning managed objects, but moving the heavy lifting to an independent Elasticsearch service.

Elasticsearch integration status

This is literally being developed right now, so do not expect this to be feature complete nor reliable enough to run in a production system. Still, we already have a great set of features working so it’s a nice time to start playing with it and hopefully provide some feedback.

The documentation sports a new Elasticsearch chapter, which is a good place to start.

Configuring the Elasticsearch backend

Dependencies

You’ll need a new dependency, named org.hibernate:hibernate-search-backend-elasticsearch.

The Maven dependencies for Hibernate Search with Elasticsearch:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-backend-elasticsearch</artifactId>
   <version>5.6.0.Alpha2</version>
</dependency>
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.6.0.Alpha2</version>
</dependency>

Configuration options

Point it to your Elasticsearch node

hibernate.search.elasticsearch.host http://127.0.0.1:9200

Enable the backend to be used for all your indexed entities

hibernate.search.default.indexmanager elasticsearch

Allow it to destroy and create indexes

hibernate.search.elasticsearch.index_management_strategy CREATE_DELETE

For details about these configuration options see the Reference documentation.

Updating the indexes

As with Lucene in embedded mode, the indexes are updated automatically when you create or update entities which are mapped to Hibernate Search using the same annotations already familiar from our traditional index mapping (see Mapping entities to the index structure).

Running a query on an Elasticsearch mapped entity

In many cases the existing way (see Querying) of running queries should work: we do automatically translate the most common types of Apache Lucene queries and many of the queries generated by the Hibernate Search DSL.

On top of translating Lucene queries, you can directly create Elasticsearch queries by using either its String format or a JSON format:

Creating an Elasticsearch native query from a string:

FullTextSession fullTextSession = Search.getFullTextSession(session);
QueryDescriptor query = ElasticsearchQueries.fromQueryString("title:tales");
List<?> result = fullTextSession.createFullTextQuery(query, ComicBook.class).list();

Creating an Elasticsearch native query from JSON:

FullTextSession fullTextSession = Search.getFullTextSession(session);
QueryDescriptor query = ElasticsearchQueries.fromJson(
      "{ 'query': { 'match' : { 'lastName' : 'Brand' } } }");
List<?> result = session.createFullTextQuery(query, GolfPlayer.class).list();

Remaining work ahead

This is an early preview, and while we’re proud of some of the progress there are several areas which still need much coding. On the other hand, implementing some of these is not very hard: this might be the perfect time to join the project.

Please check with JIRA and the mailing lists for updates, but at the time of writing this at least the following features are known to not work yet:

  • Analyzer definitions are not being applied

  • Spatial queries need more work

  • Filters can’t be applied yet

  • Faceting is mostly implemented

  • Scheduled index optimisation is not applied

  • Query timeouts

  • Delete by queries

  • Resolution for Date type mapping is ignored

  • Scrolling on large results won’t work yet

  • MoreLikeThis queries

  • Mixing Lucene based indexes and Elasticsearch based indexes

Any aspect related to performance and efficiency will also be looked at only at the end of basic feature development.

API Changes

In the 5.x series we will keep backward compatibility.

That might come at a cost of not perfect Hibernate Search / Elasticsearch integration API wise. This is something we will address in the 6.x series. But our focus is on offering the right set of features and get feedback in 5.x before improving the APIs.

In a nutshell, 6.x will depend on how you use this feature in 5.6.

How to get this release

Everything you need is available on Hibernate Search’s web site.

Get it from Maven Central using the above coordinates.

Downloads from Sourceforge are available as well, but these don’t contain the Elasticsearch integration components yet. Similarly the WildFly modules also are not including the new Elasticsearch extensions yet.

Feedback

Feedback always welcome!

Please let us know of any problem or suggestion by creating an issue on JIRA, or by sending an email to the developer’s developer’s mailing lists, or posting on the forums.

We also monitor Stack Overflow; when posting on SO please use the tag hibernate-search.

Version 5.5.2.Final is now available, our latest stable version sporting integration with Hibernate ORM 5 and Apache Lucene 5.3 - the state of the art.

Creating this version to be compatible with these two great OSS projects kept us busy for a good deal of this past year; I remember discussing this option with superstar OSS contributors Uwe Schindler (Apache Lucene developer) and Gustavo Nalle (Infinispan developer) at FOSDEM in January 2015! I am grateful to both for their guidance and suggestions, as driving progress forward is sometimes challenging when we strive to keep backwards compatibility as best as we can.

On top of that, our same small but amazing team as been working hard on Hibernate OGM 5, a bit of Hibernate Validator, incredible performance improvements on Hibernate ORM "classic" and is still tinkering on the internals of Hibernate Search to make an Elasticsearch backend an alternative to plain Lucene.

Feel like helping with the Elasticsearch integration?

Version 5.6 will feature an experimental integration with Elasticsearch. Early feedback would be very welcome! If you feel like helping, quite some code is integrated in the master branch already and there are clear TODO and FIXME comments to be found in the code.

Feel free to join the hacking! But best to let us know which area you feel like working on to avoid duplication of efforts and conflicting patches.

The 5.5.2.Final release and our great community

Technically I pushed the release button the 24th, but I couldn’t publish the blog until now because of travels.

On top of the improvements from previous 5.5.1.Final release which sported significant performance improvements, this version now incorporates several important corrections by Yoann Rodière and Guillaume Smet around metadata which was producing incorrect range queries for embedded numeric types.

Yoann also contributed another great performance improving patch, by limiting the recursion triggered by @ContainedIn more strictly, by considering the indexed paths and not just the recursion depth. You might not notice this if you have very simple flat models, but this can provide a very significant boost for all those of you using Hibernate Search to index rich models with extensive usage of @ContainedIn annotations.

Many thanks to Yoann and Guillaume, they are "power users" who do the right thing: their hands-on regular feedback is invaluable, not to mention they send such great patches for everybody else to benefit from. Not least, this is very encouraging for us: let us know which great things you’re building with these libraries!

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.5.2.Final</version>
</dependency>
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>5.0.6.Final</version>
</dependency>
<dependency>
   <groupId>org.apache.lucene</groupId>
   <artifactId>lucene-core</artifactId>
   <version>5.3.1</version>
</dependency>

How to get this release

Everything you need is available on Hibernate Search’s web site. Download the full distribution from here, or get it from Maven Central using the above coordinates, and don’t hesitate to reach us in our forums or mailing lists.

Hibernate Search 5.5.1.Final is now available!

Feedback about our recent 5.5.0.Final release has been great, and while the good news is that nobody reported significant issues, some people also pointed out that the new sorting system was a bit limited.

So we’ve been working on enhancing the FieldBridge API to make sure that those more expert users who implement their own bridging would have a better control on how sorting works as well.

We’ve also started some work to push the performance higher, and overall I’m proud to state that this 5.5.1.Final release is including some small internal polish, but results in measurable improvements.

Sorting & FieldBridge improvements

If you create custom FieldBridge implementations, you can now declare field metadata to benefit from the improved sorting performance.

Since Hibernate Search 5.5, we recommend you explicitly mark which fields will be used for sorting via the @SortableField annotation.

This has an effect on indexing and triggers improved query performance as long as Hibernate Search understands it can use the new more effective sorting strategy.

As kindly reported by Ashot Golovenko, when implementing a custom FieldBridge there was no way to let the Hibernate Search Engine component know which custom created fields are valid to sort on, so even if your implementation was clever enough to index fields appropriately to take advantage of the new sorting capabilities, this wouldn’t be used at query time.

This has been fixed by introducing an extension to FieldBridge: org.hibernate.search.bridge.MetadataProvidingFieldBridge which allows you to configure the metadata correctly. Beware though: this approach is meant for expert users, and the Query engine is going to trust that the metadata you define is actually reflected by what your bridge implementation writes into the index. In case of mismatches, you’ll have runtime exceptions during query time when sorting on a field which wasn’t indexed as declared.

Spot inefficient sorting operations easily in test suites

While Hibernate Search already would log a warning when forced to perform a query using a sub-optimal sorting strategy, that wasn’t making it very easy to spot mapping or usage mistakes.

You can now set this property:

    hibernate.search.index_uninverting_allowed = false

and you’ll have your tests fail with a reasonable exception rather than log the warning.

Performance improvements

There are many internal improvements related to performance.

The most interesting one is that now we’ll be able to automatically skip scoring in various index housekeeping operations. This implies you’ll see lower CPU usage on some index write and update operations, and also improved query performance when certain automatic filtering needs to be applied on your queries, such as for narrowing down the entity types, apply sharding related filtering.

The sorting operations have been improved as well: we can now skip the index uninverting process when sorting on distances during spatial queries, or when sorting by scores.

Memory usage has been reduced as well! Special thanks to Andrej Golovnin to have diagnosed and reported HSEARCH-2029, that fix alone will reduce our permanent memory usage.

We also reduced allocation of several short lived but heavy objects being used during indexing and query execution, overall this should improve the efficiency of the JVM.

The performance work is an on-going challenge: I’m quite happy to see very respectable figures, but we’re planning even more improvements, and if you have profiling data or other useful data to share don’t be selfish and share it! Always happy to improve it further.

Components upgrades

Several components were upgraded; most notably we’re now using the latest Apache Lucene version 5.3.1.

  • Upgrade Narayana to 5.2.5.Final

  • Upgrade JGroups to 3.6.6.Final

  • Upgrade Hibernate ORM to 5.0.4.Final

  • Upgrade Apache Lucene to 5.3.1

  • Upgrade to Hibernate Commons Annotations 5.0.1.Final

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.5.1.Final</version>
</dependency>
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>5.0.4.Final</version>
</dependency>
<dependency>
   <groupId>org.apache.lucene</groupId>
   <artifactId>lucene-core</artifactId>
   <version>5.3.1</version>
</dependency>

Next?

We’re working on version 5.6, as previously announced it’s going to sport an experimental integration with Elasticsearch.

How to get this release

Everything you need is available on Hibernate Search’s web site. Download the full distribution from here, or get it from Maven Central using the above coordinates, and don’t hesitate to reach us in our forums or mailing lists.

Releasing Hibernate Search 5.5.0.CR1

Posted by    |       |    Tagged as Hibernate Search Releases

The first Candidate Release for Hibernate Search 5.5 is now available, introducing integration with Apache Lucene 5.3 and several nice improvements.

As a reminder on versions: Hibernate Search now requires Hibernate ORM 5.0.0.Final at least, and at the time of writing only Infinispan 8.0.1.Final supports real time replication of an Apache Lucene 5.3 index.

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.5.0.CR1</version>
</dependency>
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-core</artifactId>
   <version>5.0.1.Final</version>
</dependency>
<dependency>
   <groupId>org.infinispan</groupId>
   <artifactId>infinispan-directory-provider</artifactId>
   <version>8.0.1.Final</version>
</dependency>
<dependency>
   <groupId>org.apache.lucene</groupId>
   <artifactId>lucene-core</artifactId>
   <version>5.3.0</version>
</dependency>

Out of the box indexing of java.time types

Hibernate Search is now able to automatically provide a sensible mapping for java.time.Year, java.time.Duration java.time.Instant, java.time.LocalDate, java.time.LocalTime, java.time.LocalDateTime, java.time.LocalTime, java.time.MonthDay, java.time.OffsetDateTime, java.time.OffsetTime, java.time.Period, java.time.YearMonth, java.time.ZoneDateTime, java.time.ZoneId, java.time.ZoneOffset.

That means that it includes an out of the box FieldBridge for each of these types, and allows transparent indexing and querying of properties of these types. You can of course customize the indexing by providing your own FieldBridge, as usual.

This feature is only available if you are running on a Java 8 runtime, although all other features of Hibernate Search are still backwards compatible with Java 7.

Sorting improvements

Since Apache Lucene 5.0 (and including 5.3 as we currently require) we can provide a significant performance improvement if you let us know in advance which fields you intend to use for sorting.

For this purpose a new annotation org.hibernate.search.annotations.SortableField is available. If you start using this annotation in your projects you’ll benefit from improved performance, but for those who don’t want to update their mapping yet we will fallback to the older strategy.

This subject is discussed in detail in this follow-up post.

Encoding null tokens in your index

When using @Field(indexNullAs=) to encode some marker value in the index, the type of the marker is now required to be of a compatible field type as all other values which are indexed in that same field.

This was problematic for `NumericField`s, the ones optimised for range queries on numbers, as we would previously allow you to encode a string keyword like 'null': this is no longer allowed, you will have to pick a number to be used to represent the null value.

As an example for an "age" property you might want to use:

@Field(indexNullAs = "-1")
Integer nullableAge;

How to get this release

Everything you need is available on Hibernate Search’s web site. Download the full distribution from here, or get it from Maven Central using the above coordinates, and don’t hesitate to reach us in our forums or mailing lists.

Feedback always welcome! Please let us know of any problem before we release the Final version.

After two candidate releases and a bit of quiet time in waiting for Hibernate ORM 5.0.0.Final, we now published Hibernate Search 5.4.0.Final: the first stable release compatible with ORM 5.

Minimal API changes

This version is designed to minimize your work to upgrade the Hibernate stack, so that you can focus on the changes needed to get running with Hibernate ORM 5 without having to deal with changes in the Search API.

Plans for WildFly 10, Lucene 5

WildFly 10 is coming fast and will feature both Hibernate ORM 5 and Hibernate Search, so please take advantage of this Hibernate Search 5.4.0.Final release as a milestone to get your applications up to date.

In WildFly 10 however we plan to include a further evolved version of Hibernate Search, to also update Apache Lucene to the latest (currently Lucene 5.3).

So the plan is that we’ll include some evolution of Hibernate Search 5.5.x in WildFly 10, but upgrading both ORM and Lucene could be a lot of changes for you to face in one sprint so I highly recommend using this version 5.4.0.Final as an intermediate, reliable refactoring step.

Other improvements

Since the main mantra for this version was "don’t change anything" (except the Hibernate ORM version), the new and cool stuff will be coming in the next minor release.

Of course we also fixed some minor bugs; the most relevant ones are in the area of the Query DSL, improving the handling of null-tokens during query generation and better recognition of Numeric Fields.

For details, see:

  • HSEARCH-1981 QueryBuilder should not tokenize the null-token when searching for null

  • HSEARCH-1973 Make sure the metadata recognizes a field as Numeric even if it’s wrapped into a NullEncodingTwoWayFieldBridge

  • HSEARCH-1968 Avoid the NPE on empty results during a Faceting Query

Special thanks to Marcel Barbosa Pinto for identifying and fixing the NPE on Faceting queries!

How to get this release

Everything you need is available on Hibernate Search’s web site. Download the full distribution from here, or get it from Maven Central, and don’t hesitate to reach us in our forums or mailing lists.

In the last couple of months we’ve been working to upgrade Hibernate Search to use Apache Lucene 5, to keep up with the greatest releases from the Lucene community.

Today Hibernate Search 5.5.0.Alpha1 is available!

As the version suggests this is the first cut, but we’ll also need your feedback and suggestions to better assess the needed steps to evolve this into a great, efficient and stable Final release.

A stable API

As Uwe Schindler - a great developer from the Lucene community - had suggested me to try, it turns out it was possible to update from Apache Lucene version 4 to 5 (a major upgrade) in a minor upgrade of Hibernate Search: many things improved, some things are slightly different, but overall the API was not affected by any significant change.

You might be affected by some minor changes of the Lucene API if you were writing power-use extensions to Hibernate Search, in that case:

Please let us know if there are difficulties in upgrading: we can try to improve on that, or at least improve the migration guide. If you don’t tell us, we might not know and many other developers will have a hard time!

Improved Performance

Several changes in the Apache Lucene code relate to improved efficiency, in particular of memory usage.

However our aim for this release was functionality and correctness; we didn’t have time to run performance tests, and to be fair even if we had the time nothing beats feedback from the community of users.

We would highly appreciate your help in trying it out and run some performance tests, especially if you can compare with previous versions of Hibernate Search (based on earlier versions of Apache Lucene).

If you think you can try this, it’s a unique opportunity to both contribute and to get our insight and support to analyse and understand your performance reports!

Sorting and Faceting: use the right types!

It appears that when using Apache Lucene 4, if you were running a Numeric Faceting Query but the target field was not Numeric, it would still work - or appear to work.

Similarly, if you Sort a query using the wrong SortType, Apache Lucene 4 appears to be forgiving.

When using Apache Lucene 5 now, and also because of some internal changes we had to do to keep your migration cost easier, the validation on the right types got much stricter.

Please be aware that you’ll get runtime exceptions like the following when mistmaching the types:

Type mismatch: ageForIntSorting was indexed with multiple values per document, use SORTED_SET instead

I’m aware those are confusing, so we’ll working on improving the errors: HSEARCH-1951; still even with those error messages, the meaning is you have to fix your mapping. No shame in that, we figured this problem out as several unit tests were too relaxed ;-)

How to get it

Everything you need is available on Hibernate Search’s web site. Download the full distribution from here, or get it from Maven Central, and don’t hesitate to reach us in our forums or mailing lists.

back to top