Hi all,

it's an excellent suggestion but I agree that it's not a simple problem and that it requires some help from the external deployment process, so we'll need to learn more about this before committing to a strategy.

Let's keep the issue open, optimistically scheduled for 6.x as Yoann Rodière suggested. We'll have to revisit this, more ideas and feedback welcome.

In version 6 we'll try to better differentiate between an "index name" as a logical name for Hibernate Search usage and the index names being used within Elasticsearch. Adding a configuration property to control the prefix (as mentioned above) for example could be useful, but I believe it would be too confusing without a clear separation of the various types of "index name"s we currently have.

For people not relying on events for indexing (e.g. you want to rebuild the index every night and disable the event listeners) the concerns about losing some events might not apply: if others are interested in such a feature and could explain their re-indexing strategy we can revisit this if there's any need; I believe such users can simply invoke some ES management code after their indexing node is done with the MassIndexer job so unless I'm wrong there's no need for changes from our part?

Thanks!