See org.hibernate.search.backend.spi.WorkType, org.hibernate.search.engine.impl.WorkPlan.PerClassWork#addWork, org.hibernate.search.engine.impl.WorkPlan.PerEntityWork#addWork.
See also org.hibernate.search.mapper.pojo.work.spi.PojoMappingWorkExecutor#optimize, org.hibernate.search.mapper.pojo.work.spi.PojoMappingWorkExecutor#purge, org.hibernate.search.mapper.pojo.work.spi.PojoMappingWorkExecutor#flush.
Ignore DeleteByQuery, we will handle that in .
API we agreed on during the August 2018 face-to-face meeting when discussing DeleteByQuery:
Note that we pass options in a way that is slightly different from the predicate DSL, for example. That's mainly so that the call to executeDeleteByQuery(...) executes the query directly; if we offered an API such as deleteByQuery().setSomeOption()....execute(), users could forget the call to execute and would end up not noticing that the query wasn't executed. Another option, maybe, would be to expose something like prepareDeleteByQuery().setSomeOption()....execute()?
Note that this new API will serve as an example for all future "write" APIs:
that allow to create works on a given entity, a whole indexed type, or even a set of indexed types
and/or that are specific to one technology in particular (Lucene, Elasticsearch, …).
Among these future APIs:
For Elasticsearch, the ability to execute native requests (more or less provide a path template along with a JSON string representing the payload) could be very useful.