Red Hat

In Relation To Elasticsearch

In Relation To Elasticsearch

We just published Hibernate Search version 5.8.0.Beta3, with bugfixes and improvements over 5.8.0.Beta2, but also new features such as analyzer providers, normalizers, AWS compatibility and SPIs for integration of dependency injection frameworks!

Hibernate Search 5.8.x, just as 5.7.x, is only compatible with Hibernate ORM 5.2.3 and later.

If you need to use Hibernate ORM 5.0.x or 5.1.x use the older Hibernate Search 5.6.x.

About 5.8

Hibernate Search 5.8 is mainly about:

  • making the Elasticsearch integration compatible with Elasticsearch 5.x (done);

  • improving performance of the Elasticsearch integration (in progress);

  • introducing a new DSL for defining analyzers (done);

  • ensuring that Hibernate Search will work with Java 9 (done, though Java 9 may still change);

  • improving and documenting WildFly Swarm integration (in discussion);

  • removing the need for class definition on master nodes in JMS/JGroups integration (in discussion);

  • and of course, fixing reported bugs.

You can have a look at the roadmap for more details.

What’s new since Beta2?

Programmatic analyzer definitions

You can now define your analyzers programmatically (without annotations), globally (without putting the definition on a particular entity), and in a native way (without using Lucene classes to configure an Elasticsearch analyzer) using analyzer definition providers.

For example, for Lucene your LuceneAnalysisDefinitionProvider might look like this:

public static class CustomAnalyzerProvider implements LuceneAnalysisDefinitionProvider {
    @Override
    public void register(LuceneAnalyzerDefinitionRegistryBuilder builder) {
        builder
                .analyzer( "myAnalyzer" )
                        .tokenizer( StandardTokenizerFactory.class )
                        .charFilter( MappingCharFilterFactory.class )
                                .param( "mapping", "org/hibernate/search/test/analyzer/mapping-chars.properties" )
                        .tokenFilter( ASCIIFoldingFilterFactory.class )
                        .tokenFilter( LowerCaseFilterFactory.class )
                        .tokenFilter( StopFilterFactory.class )
                                .param( "mapping", "org/hibernate/search/test/analyzer/stoplist.properties" )
                                .param( "ignoreCase", "true" );
    }
}

While for Elasticsearch you would have:

public static class CustomAnalyzerProvider implements ElasticsearchAnalysisDefinitionProvider {
    @Override
    public void register(ElasticsearchAnalysisDefinitionRegistryBuilder builder) {
        builder.analyzer( "tweet_analyzer" )
                .withTokenizer( "whitespace" )
                .withCharFilters( "custom_html_strip" )
                .withCharFilters( "p_br_as_space" );

        builder.charFilter( "custom_html_strip" )
                .type( "html_strip" )
                .param( "escaped_tags", "br", "p" );

        builder.charFilter( "p_br_as_space" )
                .type( "pattern_replace" )
                .param( "pattern", "<p/?>|<br/?>" )
                .param( "replacement", " " )
                .param( "tags", "CASE_INSENSITIVE" );
    }
}

As you can see, this allows you to avoid needing to refer to Lucene classes to configure Elasticsearch analyzers.

More details can be found here for Lucene and here for Elasticsearch.

Normalizers for safer sorts

In HSEARCH-2726 and HSEARCH-2659 we introduced normalizers: analyzers that do not perform any kind of tokenization.

We shamelessly borrowed this concept from Elasticsearch, but implemented it in both embedded Lucene mode and Elasticsearch mode. Normalizers are useful for sortable fields: when a field is sortable it should never be tokenized, as this would make the sort order unpredictable; the sort could apply to the first token if you’re lucky, but it could be applied on any other token.

From version 5.8.0.Beta3 onwards, Hibernate Search will log warnings whenever you’re using an analyzer on a sortable field. To resolve this warning change your Analyzer definition to be a Normalizer.

In Lucene, normalizers are just here to help, they work exactly as analyzers. The two differences are that you can’t affect a tokenizer to a normalizer when defining it, and that normalizers have a runtime safety net: should you manage to create multiple tokens, Hibernate Search will concatenate them back to a single token and log a warning.

In Elasticsearch version 5.2 and above, a normalizer will be translated to a native Elasticsearch normalizer, and a text field with a normalizer will take the keyword datatype.

In Elasticsearch version 5.1 and below, native normalizers are not available, thus normalizers are simply translated to analyzers and a text field with a normalizer will take the text (5.x) or string (2.x) datatype.

You can find out more about normalizers in the reference documentation:

AWS compatibility

AWS requires specific, dynamically computed headers in HTTP requests to handle authentication, which until now has made it difficult to use Hibernate Search with an AWS-hosted Elasticsearch.

We introduced a new SPI allowing low-level configuration of the HTTP client, which allows you to plug in the code required to perform the required AWS authentication; this same SPI may be used to integrate with other cloud providers.

We currently have all of our test suite running successfully against an Elasticsearch cluster managed by AWS, with security turned on.

At this stage the SPI is available but we didn’t release the signing component yet; this will be availble in the next milestone: see introduce an AWS module if you want to help!

Dependency injection in FieldBridges

As part of HSEARCH-1316, we’re experimenting with integration with various dependency injection frameworks.

The integration is about allowing you to use annotations such as @Inject, @PostConstruct and so on in your FieldBridges, which may for example allow you to fetch additional data from your application when indexing a given bean.

Integration is currently known to work with Spring DI and CDI. We don’t provide packages for user consumption, but if you are an integrator, or simply if you feel like it, you can have a look at our integration tests:

And more!

A summary of other notable changes:

  • HSEARCH-2606: the discovery_scheme configuration property is now correctly taken into account. Thanks to Matthieu Vincent for reporting and fixing this issue!

  • HSEARCH-2477: shard filtering now works on Elasticsearch.

  • HSEARCH-2603: we now use the Painless scripting language when doing spatial searches on Elasticsearch 5+. Incidentally, this means that it is no longer necessary to perform any server-side configuration on Elasticsearch 5+ to perform any spatial query.

  • HSEARCH-2734: due to a lot of confusion and incorrect (harmful) use, we have deprecated the "ram" name for the RAMDirectory directory provider. If you need it, please ensure you are not using it in a production environment, read about its limitations in the reference documentation, and use its new name: "local-heap".

  • HSEARCH-2735: index-time boosting features (@Boost, @DynamicBoost) have been deprecated with no replacement, and will need to be removed in a future version because Lucene 7 won’t allow index-time boosting anymore. See the reference documentation for alternatives: the suggestion is to switch to using query-time boosting instead.

  • HSEARCH-2665: IndexingInterceptor is no longer considered experimental.

  • HSEARCH-2666: IndexControlMBean is no longer considered experimental.

For a full list of changes since 5.8.0.Beta2, please see the release notes.

How to get this release

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.8.0.Beta3</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.8.0.Beta3</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Today is a good time for some maintenance releases of Hibernate Search.

We released all three branches currently in maintenance mode:

Version 5.5.7.Final

Maintained as it’s included in WildFly, compatible with Hibernate ORM 5.0 and 5.1: change log.

Version 5.6.2.Final

Latest stable version compatible with Hibernate ORM 5.0 and 5.1, including first experimental support for Elasticsearch: change log.

Version 5.7.1.Final

Stable version compatible with Hibernate ORM > 5.2.3.Final and later: change log.

The master branch is also very active! Expect a new Beta release of version 5.8 with support for Elasticsearch 5+ later this week.

Why ?

We backported various small fixes which should be welcome but of low impact. The big deal is HSEARCH-2691, as you might fail to notice this problem until testing under load, which is quite inconvenient.

Big thanks to Andrej Golovnin, who spotted the problem and shared a patch; I suspect it wasn’t easy to find the problem.

Also thanks to Osamu Nagano, who pointed out the importance of this fix and suggested backporting it urgently.

How to get these releases

All versions are available for download on Hibernate Search’s web site.

Ideally use a modern build tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.1.Final</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.7.1.Final</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback

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.

We just published Hibernate Search version 5.8.0.Beta2, with bugfixes and improvements over 5.8.0.Beta1.

Hibernate Search 5.8.0.Beta2, just as 5.7.0.Final, is only compatible with Hibernate ORM 5.2.3 and later.

If you need to use Hibernate ORM 5.0.x or 5.1.x and cannot upgrade, please use Hibernate Search 5.6.1.Final.

About 5.8

Hibernate Search 5.8 is about:

  • making the Elasticsearch integration compatible with Elasticsearch 5.x (done);

  • improving performance of the Elasticsearch integration (in progress);

  • introducing a new DSL for defining analyzers (in progress);

  • ensuring that Hibernate Search will work well with Java 9 (done, though Java 9 may still change);

  • improving and documenting Wildfly Swarm integration (in discussion);

  • removing the need for class definition on master nodes in JMS/JGroups integration (in discussion);

  • and of course, fixing reported bugs.

You can have a look at the roadmap for more details.

What’s new since the first Beta?

For a full list of changes since 5.8.0.Beta1, please see the release notes.

Below is a summary of the main changes:

  • HSEARCH-2606: duplicate parameters in analyzer definitions are now detected automatically and trigger an error on startup.

  • HSEARCH-2014 (local Lucene indexes only): index size is now reported as part of Hibernate Search statistics, available over JMX in particular if enabled.

  • HSEARCH-2208: use of org.apache.lucene.search.Filter throughout the APIs has been deprecated. You should use org.apache.lucene.search.Query instead, because org.apache.lucene.search.Filter will be removed when we next upgrade the Lucene dependency (in Hibernate Search 6). See the updated documentation for examples on how to achieve filters using queries (you might need to refresh your browser cache to see the latest version of the documentation).

  • HSEARCH-2675: master election when the current master fails now works correctly with the JGroups backend.

  • HSEARCH-1886: we made preliminary changes to make dynamic sharding work correctly with replicated (JGroups/JMS) backends. You can follow progress on HSEARCH-2676.

  • HSEARCH-2502: the worker can now be set to execute works asynchronously even when using Elasticsearch, by setting the same *.worker.execution configuration option as when using local Lucene indexes.

We’d also like to thank Andrej Golovnin for his work on HSEARCH-2691, fixing a bug related to query caching.

How to get this release

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

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

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.8.0.Beta2</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Just a quick heads-up to French-speaking developers: I will be presenting the Elasticsearch integration in Hibernate Search at the Strasbourg Java User Group (ElsassJUG) meetup, at 7 PM on Wednesday 26th of April.

I will briefly introduce full-text search (why and how it’s done), then present how to use Hibernate Search to keep Lucene indexes in sync with your Hibernate ORM entities, and I will show you how easy it is to target Elasticsearch instead of local Lucene indexes since Hibernate Search 5.6.0.

For more information about the location or to register, please refer to the Meetup page.

We just published Hibernate Search version 5.8.0.Beta1, which is now compatible with Elasticsearch versions 5.x.

New improved Elasticsearch client

This release now uses the new Elasticsearch REST client, which is expected to be a safe choice in terms of long term maintenance as it’s sponsored and recommended by the Elasticsearch team.

Compared to the driver we used previously, this one uses a state of the art reactive architecture, so we can take advantage of more efficient resource utilization.

Elasticsearch 2.x is still supported

The new driver is backwards compatible, so we’ll still be able to connect to clusters running Elasticsearch 2.x.

This doesn’t need any configuration flag as Hibernate Search can automatically detect the version of Elasticsearch it’s being pointed to.

The features supported by Elasticsearch 5.x and 2.x are however slightly different and you’ll find that some low level mapping features are documented as compatible with only one specific version.

The migration guide will be updated when this minor release will be feature complete.

New Simple Query String supported by the Query builder DSL

The useful capabilities from Lucene’s SimpleQueryParser are now conveniently exposed by our higher level DSL.

We’ll publish a detailed blog about this new feature soon: stay tuned!

If you can’t wait, we won’t prevent you from peeking into the Simple Query String documentation.

Simplified JNDI configuration

If you integrated any external component into Hibernate Search using JNDI, for example a JMS queue or an Infinispan cache, this configuration was simplified.

You will no longer need to set Hibernate Search specific configuration properties such as how to set the InitialContext for JNDI lookups: only configure Hibernate ORM, and Hibernate Search will inherit the same settings.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.8.0.Beta1</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.8.0.Beta1</version>
</dependency>

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.

You asked for it, we deliver: Hibernate Search 5.7.0.Final, with support for Hibernate ORM 5.2.8, is out! And of course, like previous versions, it features experimental support for Elasticsearch integration (even with some improvements).

Stuck on an older ORM version? Don’t worry, we also released a bugfix version for 5.6, namely 5.6.1.Final.

Hibernate Search 5.7.0.Final is only compatible with Hibernate ORM 5.2.3 and later. There isn’t any version of Hibernate Search compatible Hibernate ORM 5.2.0 to 5.2.2.

If you need to use Hibernate ORM 5.0.x or 5.1.x and cannot upgrade, please use Hibernate Search 5.6.1.Final.

What’s new on 5.7 since the candidate release?

Below are the main changes since the candidate release.

If you are looking for advice on how to migrate, please refer to the migration guide.

For a full list of changes since 5.7.0.CR1, please see the release notes. For a full list of changes since 5.6.0.Final, please see this list of tickets on our JIRA instance.

General improvements

  • HSEARCH-2574: when it makes sense, you can now repeat Hibernate Search annotations on a single attribute/method. For example, if you want to add two index fields on the same title attribute, you can write:

        @Field(analyzer = @Analyzer(definition = "myAnalyzer")
        @Field(name = "title_sort", analyzer = @Analyzer(definition = "myAnalyzerForSort")
        private String title;

    Thus you don’t have to use the composite annotations (@Fields) anymore. But of course, those are still available.

  • HSEARCH-2588: some methods in the Sort DSL allowed to specify the sort field type explicitly, which was useful when sorting on fields added through custom field bridges. We improved support for MetadataProvidingFieldBridge, so that you now only need to implement this interface on your custom field bridges, and won’t need anything special when using the sort DSL anymore. As a result, the byField(String, SortField.Type) and andByField(String, SortField.Type) methods in the sort DSL have been deprecated.

  • HSEARCH-2587: an NPE could occur when using the Sort DSL to sort on embedded (@IndexedEmbedded) fields; this is now fixed.

  • HSEARCH-2576: unnecessary memory allocations within queries have been removed, resulting in better query throughput.

  • And several improvements for other solutions integrating Hibernate Search, like HSEARCH-2597, HSEARCH-2561, HSEARCH-2418 or HSEARCH-2585.

Elasticsearch-specific improvements

  • HSEARCH-2453: Elasticsearch authentication is now fully implemented: there are dedicated username and password properties so that you don’t need to embed the credentials in the URL anymore.

  • HSEARCH-2593: when using automatic node discovery on Elasticsearch, a scheme (HTTP or HTTPS) cannot be detected automatically for newly discovered nodes; by default it is HTTP. You can now customize this to use HTTPS instead: just add hibernate.search.default.elasticsearch.discovery.default_scheme https to your configuration.

  • HSEARCH-2590: queries using pagination could allocate too much memory in certain circumstances; this is now fixed.

What’s new on 5.6?

5.6.1.Final contains exclusively backported fixes from 5.7. You can see a full list of changes since 5.6.0.Final in the release notes.

What’s next?

We’re now focusing on the next two big improvements:

  • support for Elasticsearch 5 without losing support for Elasticsearch 2 (HSEARCH-2434, HSEARCH-2581). This will be in a 5.8 release.

  • streamlining our APIs, in particular to better fit remote indexing services (like Elasticsearch), but also to support Lucene 6. Due to the breaking changes this requires, we will include these changes in a new major release, Hibernate Search 6.0.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.Final</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.7.0.Final</version>
</dependency>

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

After a relatively quiet candidate release, we just published Hibernate Search version 5.6.0.Final with experimental Elasticsearch integration, along with 5.7.0.CR1.

Version 5.6.0.Final brings the latest bugfixes for our experimental Elasticsearch integration. This is the version to use with Hibernate ORM versions 5.0 and 5.1.

Version 5.7.0.CR1 brings the exact same changes as 5.6.0.Final, and now features the compatibility with Hibernate ORM version 5.2.7 (but not lower than 5.2.3, see more on this further down).

What’s new on 5.6 since the candidate release?

Below are the main changes since the candidate release.

For a full list of changes since 5.6.0.CR1, please see the release notes. For a full list of changes since 5.5, please see this list of tickets on our JIRA instance.

Common changes

  • HSEARCH-2547: nesting an @IndexedEmbedded with includePaths within an @IndexedEmbedded without an includePaths will now work properly.

  • HSEARCH-2535: @Facet with string encoding will now work properly on multi-valued properties (such as String[] or List<String>).

Elasticsearch-specific changes

  • HSEARCH-2501: the handling of @CalendarBridge.resolution with Elasticsearch was aligned on the one with Lucene: they are now consistent.

  • HSEARCH-2531: with Elasticsearch, index names can now be overridden using configuration properties, just like when using Lucene. Thanks to Cary Yu for reporting the issue!

  • HSEARCH-2519 and HSEARCH-2520: the Elasticsearch VALIDATE and MERGE index management strategies now handle analyzer definitions. This will only affect you if you were using @AnalyzerDef-defined analyzers on entities that are indexed in Elasticsearch. If you are, please be aware that the MERGE strategy may now close/reopen your index automatically during bootstrap! See the reference documentation for more information about the MERGE strategy.

What’s new on 5.7?

The main change in 5.7.0.CR1 since 5.7.0.Beta2 is the upgrade to Hibernate ORM 5.2.7. For a full list of changes, see the release notes.

Please note that Hibernate Search 5.7 now requires Hibernate ORM 5.2.3 onwards, and cannot be used with previous Hibernate ORM versions.

When will 5.7 be released?

5.7 is beginning its candidate release period, meaning that as far as we are concerned, it is already ready. We are giving a last chance for the community to report bugs, and unless we are delayed by major bugs, the actual 5.7.0.Final release should happen in mid-February.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

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

Or, for Hibernate Search 5.7:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.CR1</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.6.0.Final</version>
</dependency>

Change the version to 5.7.0.CR1 in order to test the Hibernate ORM 5.2 integration.

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

It’s finally here! We just published the first candidate release of Hibernate Search with experimental Elasticsearch integration (5.6.0.CR1), along with 5.7.0.Beta2.

Version 5.6.0.CR1 brings the latest bugfixes and previously missing features for our experimental Elasticsearch integration. This is the version to use with Hibernate ORM versions 5.0 and 5.1.

Version 5.7.0.Beta2 brings the exact same changes as 5.6.0.CR1, and it still features the compatibility with Hibernate ORM version 5.2 that was introduced with 5.7.0.Alpha1.

What’s new?

  • HSEARCH-2348: Elasticsearch queries are now logged at the DEBUG level on the org.hibernate.search.fulltext_query logger, just as embedded Lucene queries.

  • HSEARCH-2449: more configuration options have been added regarding the connection to Elasticsearch, including the size of connection pools, the connection/read timeouts, and the automatic discovery of new nodes in the Elasticsearch cluster for client-side loadbalancing and (limited) failover.

  • HSEARCH-2219: analyzer definitions are now automatically translated and added to the Elasticsearch settings when Elasticsearch indexes are created. Please note there are still some limitations, most notably the definitions are not updated automatically (no support for the MERGE schema management strategy). See the documentation for more information about analyzers with Elasticsearch.

  • HSEARCH-2387: Elasticsearch mappings generated by Hibernate Search used to be strictly static. This can be an issue in some cases, which is why opt-in dynamic mappings are now available, either through a global option (see org.hibernate.search.elasticsearch.cfg.ElasticsearchEnvironment.DYNAMIC_MAPPING) or locally on metadata-providing field bridges (builder.field( name, FieldType.OBJECT ).mappedOn( Elasticsearch.class ).dynamic( DynamicType.TRUE )). Thanks to Alex Laptseu for reporting this!

  • …​ and much more, mainly bug fixes. The full change log can be found on our JIRA instance.

When will 5.6 be released?

As far as we are concerned, 5.6 is ready. Version 5.6.0.CR1 is the last opportunity for the community to test it and report bugs before the release which, if all goes well, will happen in early January.

What about Elasticsearch 5 support?

As mentioned in the blog post about the previous release, Elasticsearch 5.x is not supported yet.

Quoting:

The main reason is it brings several backward-incompatible changes that would require quite a bit of work if we still want to support the 2.x series. And we don’t want to postpone the Hibernate Search 5.6.0 release any more.

Our plan is to release a 5.6 supporting Elasticsearch 2.x, and add Elasticsearch 5 support in Hibernate Search 6.0 or, maybe, in an early 5.8 release. You may refer to HSEARCH-2434 to track the status of Elasticsearch 5.0 support.

When will 5.7 be released?

We are planning to publish a candidate release for 5.7 soon after 5.6.0.Final has been released.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

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

Or, for Hibernate Search 5.7:

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

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.6.0.CR1</version>
</dependency>

Change the version to 5.7.0.Beta2 in order to test the Elasticsearch integration within Hibernate Search 5.7.

Downloads from Sourceforge are available as well.

Feedback, issues, ideas?

To get in touch, use the following channels:

Today we are releasing two new versions of Hibernate Search: 5.6.0.Beta4 and 5.7.0.Beta1!

Version 5.6.0.Beta4 brings the latest bugfixes and previously missing features for our experimental Elasticsearch integration. This is the version to use with Hibernate ORM versions 5.0.x and 5.1.x.

Version 5.7.0.Beta1 brings the exact same changes as 5.6.0.Beta1, but on top of the compatibility with Hibernate ORM version 5.2.x that was introduced with 5.7.0.Alpha1.

What’s new?

  • HSEARCH-402: A new async reader strategy has been added for the Lucene indexing service, bringing performance boosts when you are okay with your queries being run on an out-of-date index (how much out-of-date is configurable).

  • HSEARCH-2260: A new VALIDATE index schema management strategy has been added for Elasticsearch, allowing you to automatically check on startup that your Hibernate Search mappings are in line with the Elasticsearch mappings.

  • Issues with @IndexedEmbedded in the Elasticsearch integration have be addressed: everything should now work properly, with the notable exception of @IndexedEmbedded.indexNullAs (not to be confused with @Field.indexNullAs).

  • HSEARCH-2235: You can now configure Hibernate Search to send requests to Elasticsearch servers in round-robin, enabling load-balancing. Failover is not supported yet, but we’ll be working on it.

  • HSEARCH-2360: Elasticsearch projections now use source filtering, greatly reducing the bandwidth needs when retrieving results.

  • We now test our Elasticsearch integration against version 2.4.2, which fixed an issue with date formats that impacted Hibernate Search. We strongly recommend to update your 2.4.x instances to the lastest available version in the 2.4.x series.

  • …​ and much more. The full change log can be found on our JIRA instance or on our GitHub repository.

When will this 5.6.0 be released?

We’ve been caught up in the polishing work with the Elasticsearch integration lately, but we’re seeing the end of the tunnel: the list of open tasks is getting shorter and shorter. The first release candidate for Hibernate Search 5.6.0 will land by the end of next week.

So, if you haven’t tested 5.6 already, now’s the time! Should you find any bug, please report them on our JIRA instance.

What about Elasticsearch 5 support?

Please be aware that we’re not currently supporting Elasticsearch 5.x. The main reason is it brings several backward-incompatible changes that would require quite a bit of work if we still want to support the 2.x series. And we don’t want to postpone the Hibernate Search 5.6.0 release any more.

Our plan is to release a 5.6.0 supporting Elasticsearch 2.x, and add Elasticsearch 5 support in Hibernate Search 6.0 or, maybe, in an early 5.8 release. You may refer to HSEARCH-2434 to track the status of Elasticsearch 5.0 support.

When will 5.7.0 be released?

Everything is going smoothly with this version, and very few bugs have been reported. As soon as 5.6.0 will be released, we’ll publish the candidate release for 5.7.0.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

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

Or, for Hibernate Search 5.7:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-orm</artifactId>
   <version>5.7.0.Beta1</version>
</dependency>

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.6.0.Beta4</version>
</dependency>

(Change the version to 5.7.0.Beta1 in order to test the Elasticsearch integration within Hibernate Search 5.7)

Downloads from Sourceforge are available as well.

Today we have three releases of Hibernate Search!

I’m proud to announce our team is a bit larger nowadays, and more contributors are volunteering too, so we managed to increase the development pace. Today we release version 5.6.0.Beta3, 5.7.0.Alpha1 and 5.5.5.Final.

Version 5.6.0.Beta3

the latest version of our main development branch, with experimental Elasticsearch integration.

Version 5.7.0.Alpha1

essentially the same as 5.6.0.Beta3, but compatible with Hibernate ORM version 5.2.x.

Version 5.5.5.Final

a maintenance release of our stable branch.

A 5.7 preview released when 5.6 isn’t out yet?

Let me explain this unusual decision was taken to accomodate for the needs of you all.

The 5.6 series is creating a lot of anticipation with the Elasticsearch integration being a very welcome new feature; it’s meant to be an experimental new feature as we won’t break our APIs yet while all integration needs are analyzed, still it’s taking a bit longer than expected and even though it’s and experimental feature we don’t want to rush it and need to finish it up properly.

In the meantime the Hibernate ORM project released a series 5.2.x, and several users have been asking to get an Hibernate Search version compatible with it. We could not upgrade our 5.6 series yet, as then people using an older Hibernate ORM would not be able to play with the Elasticsearch integration.

So now that 5.6 is in good shape - we decided the next release will be a candidate release - we felt we could already publish a 5.7 version, which is just exactly the same but in a new branch made compatible with the very latest Hibernate ORM.

How is the Elasticsearch integration coming?

It’s maturing at high speed. The biggest obstacles have been resolved, so we definitely look out for more feedback at this point; as mentioned, the next version will be a candidate release.

Hibernate Search now has a proper Sorting API: watch this space as we’ll publish a dedicated blog about it, or get a peek at the query sorting paragraph in the documentation.

This is an important milestone, as it makes sorting queries on Elasticsearch possible through our DSL.

How to get these releases

All versions are available on Hibernate Search’s web site.

Ideally use a tool to fetch it from Maven central; these are the coordinates:

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

To use the experimental Elasticsearch integration you’ll also need:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-elasticsearch</artifactId>
   <version>5.6.0.Beta3</version>
</dependency>

Downloads from Sourceforge are available as well.

back to top