Hibernate Search is a community driven project and as such the roadmap constantly evolves to reflect the users needs.
You can find a finer grained roadmap in our issue tracker but this page is a good and concise view of where we are going.
Dates are generally omitted: milestones are released regularly, the Final release is tagged when it’s considered stable.
Hibernate Search 6.2
For a full list of issues currently planned for this series, see here.
- Better control over indexing
-
-
Hibernate Search 6.2 will provide ways to suspend automatic indexing. See HSEARCH-168, HSEARCH-1383.
-
For some use cases where maintenance downtime during mass indexing is not acceptable, Hibernate Search needs to be able to create a new copy of the index, index everything into that new copy, and replace the old copy with the new one atomically, so that clients can continue querying the old index while mass indexing is in progress, and never see an empty index (but only, at worst, an out-of-date index). See HSEARCH-3499.
-
- Hibernate Search for arbitrary data sources
-
Experimental module allowing integration with a datastore that is not accessed using Hibernate ORM.
Users will need to put in more work to configure it, in particular they will need to capture insert/update/delete events themselves.
Nevertheless, this could be useful for people looking to add full-text search to any application, not just applications relying on Hibernate ORM.
See also HSEARCH-1800.
- Search query features
-
These are rather important features when using Hibernate Search with arbitrary data sources, where loading data from the original data source might not be possible:
-
HSEARCH-3927 Projection to a DTO/JavaBean/etc.
-
HSEARCH-3943 Projection nesting: preserving the document structure in projections
-
- Mass indexing improvements
-
In particular:
-
HSEARCH-3499 Near-zero-downtime mass indexing when the schema did not change
-
HSEARCH-1032 MassIndexer with an update mechanism
-
HSEARCH-521 Improve performance of MassIndexer through Eager fetching
-
Hibernate Search 6.3
For a full list of issues currently planned for this series, see here.
- Search query features
-
Add more features to the Hibernate Search DSL. In particular:
-
HSEARCH-2192 Highlighting in the Search API
-
HSEARCH-917 Add match all terms option when matching in the DSL API
-
HSEARCH-3327 Add options for match predicates targeting multiple fields
-
HSEARCH-3926 Predicate on multiple fields designated by a single label/group name/etc. ("_all", copy_to, …)
-
- Reactive Search
-
Experiment with integrating Hibernate Search with Hibernate Reactive.
See also HSEARCH-3322, HSEARCH-3471.
Hibernate Search 6.4
For a full list of issues currently planned for this series, see here.
- More advanced mapping
-
Allow more complex setups when it comes to mapping entities to indexes. In particular:
-
HSEARCH-3971 Mapping an entity differently based on a discriminator
-
HSEARCH-3683 Mapping a single entity type to multiple indexes
-
HSEARCH-3903 Filters based exclusively on mapper metadata for @IndexedEmbedded
-
- Some specialized field types
-
Add commonly used field types. In particular:
-
Fields derived from large blobs, useful when indexing PDFs with Apache Tika for example.
-
Maybe more, depending on demand, e.g. HSEARCH-3488 Add support for nanosecond precision for temporal fields.
-
- Tracing
-
Tracing of search queries and indexing requests to enable easier debugging and performance investigation.
See HSEARCH-4057.
Hibernate Search 6.x or later
- Restore the OSGi integration
-
The OSGi integration was removed in 6.0 to reduce the work load. We will restore it in a later version if there is demand for it. Vote here.
- Free-form indexing
-
We’re planning to decouple the metadata definition from annotated java classes, to allow better indexing of other more flexible sources; for example to make it easier to index data structured in the JSON format, or other formats whose schema is not known at compile time.
- Debezium integration
-
Asynchronous indexing driven by Change Data Capture in the database instead of Hibernate ORM events.
This would allow capturing changes caused by any SQL command, not just those issued by Hibernate ORM.
See HSEARCH-3513.
