mikerhodes commented on PR #4710: URL: https://github.com/apache/couchdb/pull/4710#issuecomment-1727307260
> adding a note that for the new endpoints an index should not match a selector if it only has indexed fields where the selector does $regex or any other operator where neither startkey or endkey are changed from the defaults that cover the entire view. I disagree that we should implement this restriction. The issue the user reported is "`use_index` doesn't do what it says". It wasn't "I don't like that the database does inefficient queries". Even if it was, I'd still disagree. I do agree that a good way to solve this is to introduce the URL framing for selecting an index. But I think the only reason we'd return a 400 would be that the index in the URL would be disqualified using the standard Mango index selection logic for the given selector (eg, selector doesn't contain the fields in an "indexable" way). Specifically, I don't think the user should be prevented from passing in a selector that passes the index selection logic, but passes values which mean the entire view is read. I think this because: 1. I think this is confusing for a user --- both views and search allow this, so why have this restriction only for Mango? 2. I don't think "because the user can shoot themselves in the foot" is a good reason either, because it's not what I'd want for CouchDB to do on my behalf. Databases provide many, many ways to shoot oneself in the foot. And they should do, that's why they are powerful. In summary, I agree the URL method is a good solution to this problem, which is that `use_index` is bad because it doesn't do what it says. I'd like to get use_index deprecated and a replacement into the codebase, and avoid trying to "fix" Mango in other ways at the same time. -- 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]
