Uploaded image for project: 'Hibernate Search'
  1. HSEARCH-3460

Remove the confusion between flush and refresh

    Details

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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              yrodiere Yoann Rodière
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: