Hi,
You’re pretty much describing what the outbox-polling coordination strategy does. I suggest you have a look at this.
That coordination strategy sends entity change events to a queue in the database (a table), and has background processors to process those events and perform the indexing. When you start mass indexing, entity change events are still pushed to that queue, but the processors are temporarily stopped, until the mass indexer finishes. That all happens transparently, without you having to do anything.
That being said, schema changes are still an open problem. It’s unfortunately not as simple as notifying of problems caused by changed fields; there could also be changes in how reindexing must happen.
For example if a Book entity has no @IndexedEmbedded on its author property, then changing an author won’t trigger any event to reindex a book when an author changes. But if you change your mapping to add @IndexedEmbedded to Book#author, and someone modifies an author while you’re reindexing, there’s a chance you’ll simply have a missing event…
So, yeah, it’s not simple. We’re working on it, but it’s not going to be solved in one day. Relevant tickets: [HSEARCH-3499] - Hibernate JIRA, [HSEARCH-2861] - Hibernate JIRA (and we’re probably need to work on more than that).
I still think the outbox-polling coordination strategy would be a good idea in your case, though.