rnewson commented on PR #4710: URL: https://github.com/apache/couchdb/pull/4710#issuecomment-1660300445
the behaviour of `use_index` can't easily be changed (or, I think we'd all agree, _fixed_), short of a major version bump. If there was a roadmap here for couchdb 4.0 (handwaving, but imagine that use_index as an option goes away entirely. you either use `/dbname/_find` and let couchdb choose, or you use `/path/to/specific/index/_find` to choose for yourself). Without that, it's hard to decide whether adding more options is taking us somewhere better or just somewhere more confusing. As a user I would be legitimately baffled to be told I should use `use_index_strict` when I report that my `use_index` directive is being ignored. I'm not sure if I'm -0 or -1 on this, I'm veering to -0 though. I don't like leaving `use_index` as-is (it should never have been merely a hint) and I don't like adding another argument to do what `use_index` should have done. Hence I suggested having `_find` also reachable from a url that clearly is associated with a specific index resource, like we have for all the other kinds of index we have. That endpoint can return a 400 if the request parameters cannot be executed by the index. That idea also gives users a migration path away from the flawed choosing algorithm. A future (major) release of CouchDB might then drop `/dbname/_find` entirely. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
