i’ve problems migrating two configuration properties:
hibernate.search.massindexer.factoryclass
i cant find an entry for this property in the migration-guide. Is it not possible anymore to register a factory?
hibernate.search.default.directory_provider
this property moved to hibernate.search.backend.directory.type. I used this property to register an own directory provider by implementing a class implementing the interface org.hibernate.search.backend.lucene.lowlevel.directory.spi.DirectoryProvider. Is there a similar way to do this with version 6.x?
Hey Markus, thanks for reaching out. It’s great that you are switching to the newer version. As there are a lot of configuration options exposed for both mass indexer and directory provider, I’d like to ask if you could also share what is currently missing from the built-in functionality that you’d still want to provide your custom implementations for the things you’ve mentioned.
Then to try answer your question:
I don’t think that there’s any alternative available for this right now.
Even though the documentation provides only two options: local-filesystem and local-heap for this property you could actually pass a fully qualified class name of your own implementation and it’ll be instantiated and used. With that said I would still encourage you to check if the config properties for directories would cover your needs instead of providing the custom implementation.
i have added a CDI context to the threads because I needed the context in some bridges
In a multitenancy environment, the threads were set to a specific tenant, so that I could get discrete index files for the same entities from different tenants
if there were already better solutions or now there are, I would of course be grateful for tips
Regarding DirectoryProvider… we determine the storage location for certain reasons from a microprofile-config property. The DirectoryProvider was ideal to use for this.
In the medium term we will switch to Elasticsearch or OpenSearch. It would be nice if there was also a possibility here to be able to define the configuration parameters via a corresponding provider.
MassIndexerFactory was an SPI whose only known use was in Hibernate OGM, with no other clear use case, so it was not reimplemented in Hibernate Search 6. Let’s see how to address your use case in Hibernate Search 6, though.
I suspect [HSEARCH-1809] - Hibernate JIRA would address that, should someone send a PR. It would probably be relatively easy to implement.
I’m not sure what you were doing exactly, but I think you basically want index-based multitenancy, e.g. one Lucene index per tenant? We don’t have that feature planned at the moment, but that’s certainly a reasonable one, so feel free to create a ticket.
In the meantime, you can probably make it work with a routing bridge? You have access to the tenant identifier in the RoutingBridge.route(...) method through context.tenantIdentifier().
So this is about configuring Hibernate Search based on other sources than just the Hibernate ORM configuration?
While it would technically be possible to provide such integration points, I decided against it because there are already plenty of solutions to pre-process external configuration and turn it into Hibernate Search configuration in frameworks and Hibernate ORM itself: Spring’s has a PropertyResolver, Quarkus/MicroProfile has custom ConfigSources, but there are also ways to override Spring’s JPA bootstrap to inject additional properties, and Hibernate ORM allows overriding the default ConfigurationServie through your own implementation of StandardServiceInitiator<ConfigurationService> if necessary.
If that’s not enough… as Marko mentioned, you can always set hibernate.search.backend.directory.type to a custom implementation of org.hibernate.search.backend.lucene.lowlevel.directory.spi.DirectoryProvider. But that’s a low-level SPI, so you can expect more frequent and drastic changes than in APIs.
