We currently use the term "flush" for operations in the Elasticsearch backend that perform refreshes. See for example how {{org.hibernate.search.backend.elasticsearch.index.impl.ElasticsearchIndexWorkExecutor#flush}} uses a {{FlushWork}} which happens to also perform a refresh.
The thing is, we twisted the meaning of the flush work to also perform a refresh (see FlushWork), but traditionally flush and refreshes have a very different meaning: https://qbox.io/blog/refresh-flush-operations-elasticsearch-guide
So most of our APIs/SPIs using the word "flush" actually do more than they seem, and (worse) we rely on them doing more than they seem.
Maybe we should split flushes/refreshes more explicitly in the APIs?
In the case of the ORM mapper, since the refresh generally follows a flush, we may want to expose a {{flushToIndexes(Collection<? extends Class<?>> selection, HibernateOrmMapperFlushLevel flushLevel, HibernateOrmMapperRefreshLevel refreshLevel)}} operation, with "flushLevel" being either "backend" (just send the documents to the backend) or "storage" (also send a flush request to ES), and "refreshLevel" being one of "none", "wait" (wait for the next refresh) or "force" (force a refresh immediately). *Or maybe this will be better addressed in HSEARCH-3316 through the "level" of completion that is expected on commit (see last paragraph in the ticket description)?*
Caution: let's seem how these operations are called in Solr before we decide on how we call the "refresh". |
|
