Part of #5070. Follows #5235.
Internal code currently reads the deprecated index fields directly, and every one of those reads carries a linter suppression to silence the deprecation warning. There are 26 of them across 10 files. That is backwards: internal code should not be using anything deprecated at all, except in the one place whose job is to support it.
What to do
Resolve a request's two spellings into one at the boundary, the way descriptors already work.
A descriptor is normalized on the way in and out of storage, so anything read from the store already has its kind config filled in and nothing downstream needs to think about it. An index request has no equivalent, so each consumer resolves the spellings itself: the validation, the name generation, the field check. Doing that once where a request arrives, and clearing the deprecated field afterwards, leaves every reader downstream with only the kind config to look at.
Two suppressions should survive: the normalize function itself, where reading the deprecated field is the whole point, and possibly the CLI and C wrappers, which sit outside the boundary and translate a request into flags.
Worth checking that clearing the deprecated field after normalizing does not surprise anything that round-trips a request and reads it back, particularly over HTTP and the C bindings.
Renaming the field description
Once internal code no longer reads the deprecated fields, the shared field description type is only used by ordered indexes, and its name should say so. It carries a sort direction, which is meaningful for an ordered index and meaningless for every other kind.
Renaming it needs the usual deprecation window rather than a straight rename: the new name becomes the real type, the old name becomes a deprecated alias to it, and the alias goes away in v2.0.0 alongside the other deprecated index fields. Doing this before the normalization above would be premature, since the type is still genuinely shared until then.
Testing
Tests confirming a request built with either spelling produces the same stored index, that the deprecated spelling still works through every client, and that the rename leaves existing callers compiling.
Part of #5070. Follows #5235.
Internal code currently reads the deprecated index fields directly, and every one of those reads carries a linter suppression to silence the deprecation warning. There are 26 of them across 10 files. That is backwards: internal code should not be using anything deprecated at all, except in the one place whose job is to support it.
What to do
Resolve a request's two spellings into one at the boundary, the way descriptors already work.
A descriptor is normalized on the way in and out of storage, so anything read from the store already has its kind config filled in and nothing downstream needs to think about it. An index request has no equivalent, so each consumer resolves the spellings itself: the validation, the name generation, the field check. Doing that once where a request arrives, and clearing the deprecated field afterwards, leaves every reader downstream with only the kind config to look at.
Two suppressions should survive: the normalize function itself, where reading the deprecated field is the whole point, and possibly the CLI and C wrappers, which sit outside the boundary and translate a request into flags.
Worth checking that clearing the deprecated field after normalizing does not surprise anything that round-trips a request and reads it back, particularly over HTTP and the C bindings.
Renaming the field description
Once internal code no longer reads the deprecated fields, the shared field description type is only used by ordered indexes, and its name should say so. It carries a sort direction, which is meaningful for an ordered index and meaningless for every other kind.
Renaming it needs the usual deprecation window rather than a straight rename: the new name becomes the real type, the old name becomes a deprecated alias to it, and the alias goes away in v2.0.0 alongside the other deprecated index fields. Doing this before the normalization above would be premature, since the type is still genuinely shared until then.
Testing
Tests confirming a request built with either spelling produces the same stored index, that the deprecated spelling still works through every client, and that the rename leaves existing callers compiling.