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

Remove the confusion between flush and refresh


    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects versions: 6.0.0.Alpha1, 5.11.0.Final
    • Fix versions: 6.0.0.Beta5
    • Labels:


      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 see how these operations are called in Solr before we decide on how we call the "refresh".




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


              • Created: