When reviewing MORAY-104, Cody made the suggestion that that change should also
include the fix for the issue where sending a findObjects request for a bucket
that has fields being reindexed sends records that don't include these fields.
I have two concerns with this suggestion:
-
even though it makes sense in many use cases to have that behavior in conjunction with the behavior that checks that search fields have all usable indexes, there are use cases when one may want one and not the other
-
for a use case where a moray client needs both behavior changes (including reindexing fields in the response's record and checking that all search fields are usable indexes), the name
requireIndexesseems to not convey the intention
I'd like to explore possible solutions for these two concerns.
Possible names include:
includeUnindexedFields
includeAllFields
requireAllFieldsInRecords
The requireIndexes option could be renamed as one of the following:
strict
strictMode
safe
safeMode
Thinking about this issue made me realize that we potentially have another
problem with the current approach taken by MORAY-104, regarless of whether the
requireIndexes findObjects option includes fields being reindexed in
response's records or not.
If we want to fix/add something to any of these options later, we can't use the same option name, otherwise we wouldn't know whether the server actually supports the first, second, or later iteration of that option.
It seems the only way for a client to determine precisely what it can expect from a server is by requiring the server to be at a specific version.
We could thus pass e.g {requireIndexes: true, requireServerVersion: '1.2.3'} to
findObjects requests to make sure that the request is handled by a server that
supports the requireIndexes option, and that this server is at version 1.2.3.