Remove the confusion between flush and refresh

Description

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".

Environment

None

Status

Assignee

Unassigned

Reporter

Yoann Rodière

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Fix versions

Affects versions

Priority

Major
Configure