Deletes and re-creates index and mapping if the index definition is not in sync with an expected definition
That's super dangerous because it will delete all the existing data.
But there is an option in Beyonder here:
Using force will remove any existing index if exists. Not that it will not compare the existing schema with the one that you want to apply. That could be a good option to add to this project though. But it is still super dangerous to me and I'd only use that for integration testing not for production code.
Note that the merge option can try to update an existing mapping but it will work only in a few circonstances (like adding a new field).
Thanks for the hint! - But I am really looking for something robust that detects index definition changes and performs a complete re-creation if definitions have changed. Data loss is not an issue - ES is not the primary data store and can be rebuilt within minutes. It is just not convenient to force that kind of re-creation on every service restart.
I see three options how information about the last "valid" index definition could be persisted:
Hash the original index definition and store hash it in some metadata field in ES (I am not sure there is an appropriate field to do this - is there?)
Hash the original index definition and store hash it in a persistent location (usually File System)
Keep the original index definition and store it in a persistent location (also FS)
On startup, the current _settings.json could be checked against the persisted hash/definition and force re-creation if they don't match.
My preference would be (1) but I could not yet find an appropriate customizable metadata field at the index level. Options (2,3) require configuration of some persistent file location, which would work for me but is probably less desirable for this kind of library.