Hi @Nitesh_Gupta,
Yes, Whenever the user edits the index definition, it results in an index rebuild except for a few cases in the recent releases. (>6.5).
- Adding/removing replica partition count won’t result in index rebuild.
- Any scorch storage property change won’t result in an index rebuild.
All other index definition changes result in a rebuild. During this time, live traffic would be affected.
Ideally, these shouldn’t be a major concern for the production systems since most of these fields to index/search would have been finalized during the dev period itself.
Use Index-Alias
Now, for accommodating any production time index maintenance tasks, we have the index-alias feature which users can use to manage the index rebuilds/recreations without affecting the live traffic.
ref - Creating Indexes | Couchbase Docs
Indexes never get rebuilds by DML/CRUD operations on the documents, it only gets rebuild upon index definition changes.
FTS index will always be streaming all the latest changes into it’s index and should give the latest results.
Users can use consistency level “at_plus” and provide vectors for verifying this.
Whenever we need to read your own writes(RYOW),
then we are supposed to pass a consistency vector conveying that to the FTS back end.
Today FTS supports only `at_plus` consistency level.
In short, looks like one has to use consistentWith(MutationState) in the API calls while searching where the MutationState is derived from the previous write ops which one wants to read.
examples:
MutationResult mutationResult = collection.upsert("key", JsonObject.create());
MutationState mutationState = MutationState.from(mutationResult.mutationToken().get());
SearchResult searchResult = cluster.searchQuery(
"index",
SearchQuery.queryString("query"),
searchOptions().consistentWith(mutationState)
);
https://docs.couchbase.com/java-sdk/current/howtos/full-text-searching-with-sdk.html
https://docs.couchbase.com/java-sdk/2.7/scan-consistency-examples.html
