Hi All, I'm also +1 for this. I think getting a slow result is better than no result. Jan nice idea on the metric, not sure if you are aware of it, but we do have some basic metrics already http://docs.couchdb.org/en/latest/api/database/find.html#execution-statistics
Cheers Garren On Fri, Nov 24, 2017 at 6:38 PM, Jan Lehnardt <j...@apache.org> wrote: > I’m +1 as well. > > Not to derail this particular discussion (but watch me do it anyway ;): > it be great if we could add a metric akin to “slow queries” that gets > incremented every time we do the fallback. Ideally then this could be > shown in Fauxton is growing steadily, and external monitoring can look > at is as well. > > I’m totally fine with this landing as-is, and adding the metric later > as long as we keep an open issue for that. Would make a nice first time > contribution, too. > > Best > Jan > — > > > > On 22. Nov 2017, at 21:38, Tony Sun <tony.sun...@gmail.com> wrote: > > > > Hello Everyone, > > > > Will and I were hoping to get some more opinions for > > https://github.com/apache/couchdb/pull/962. > > > > To provide some context, Mango had a long existing bug that allowed users > > to incorrectly use an index for a query. This bug was fixed in > > https://github.com/apache/couchdb/pull/816. However, this fix can lead > to a > > breaking change for users who incorrectly used the index prior to the > fix. > > Instead of results being returned, the user will see a "no_usable_index" > > error. > > > > PR 962 mitigates this issue by essentially removing "no_usable_index". > > We either find another usable index, or perform a full table scan via > > _all_docs. > > > > Should we allow this new behavior or continue to throw errors and force > > users to create a new index? > > > > Happy Holidays! > > > > Tony > > -- > Professional Support for Apache CouchDB: > https://neighbourhood.ie/couchdb-support/ > >
