Document reindexing
Clarify flow when no change is detected
@@ -148,17 +148,20 @@ At time of execution, the job performs its work:
If no such state exists, or no such checkpoint is present,
then it treats it as initial indexing, in which case the base state is empty.
This state is considered the `before` state.
-2. Create a checkpoint for _current_ state and refer to this as `after` state.
-3. Create an `IndexUpdate` instance bound to the current _indexing lane_,
+2. Check if there has been any change in repository from the `before` state.
+ If no change is detected then current indexing cycle is considered completed and
+ `IndexStatsMBean#done` time is set to current time. `LastIndexedTime` is not updated
+3. Create a checkpoint for _current_ state and refer to this as `after` state.
+4. Create an `IndexUpdate` instance bound to the current _indexing lane_,
and trigger a diff between the `before` and the `after` state.
-4. `IndexUpdate` will then pick up index definitions that are bound to the current indexing lane,
+5. `IndexUpdate` will then pick up index definitions that are bound to the current indexing lane,
will create `IndexEditor` instances for them,
and pass them the diff callbacks.
-5. The diff traverses in a depth-first manner,
+6. The diff traverses in a depth-first manner,
and at the end of diff, the `IndexEditor` will do final changes for the current indexing run.
Depending on the index implementation, the index data can be either stored in the NodeStore itself
(for indexes of type `lucene`, `property`, and so on), or in any remote store (for type `solr`).
-6. `AsyncIndexUpdate` will then update the last indexed checkpoint to the current checkpoint
+7. `AsyncIndexUpdate` will then update the last indexed checkpoint to the current checkpoint
and do a commit.
Such async indexes are _eventually consistent_ with the repository state,
