>> - is a timeout solving the root cause or the symptoms? Could it be a >> temporary or additional step as in conjunction with query optimisation >> tooling? > > It really depends. From my CouchDB admin and user perspective, this > doesn't seem so important to me right now. However, I recognize that > there are different usage scenarios with different requirents (e.g. the > ones at Cloudant).
I don't think there's anything special about Cloudant in this discussion. Its just a question of how do we allow new users the ability to easily test and learn the selector/query API while also preventing them from going too far without creating indexes for their queries. The slow queries messages are fine, but just as any other database they don't really prompt the developer to make the correct change. Ie, the developer has to be savvy enough to a) know that the slow queries logs exist, b) understand that creating an index would speed things up, and then c) know which index to create based on the logged query. In my experience, the group of users that we're concerned about in this discussion most likely don't know about any of those three things, hence why the current API is designed to force them to learn about and understand indexes as part of learning the API. Granted the `_id > null` trick muddies that learning process. I would think that replacing the _id trick with `"testing": true` or similar would be an obvious indication to users that this is a dev/debug type feature and when they went to production they would still be pushed to using an index. If we add the "create index from selector" API then I think this would be a relatively straightforward method to on ramping to both the query and index sides of the API. Ie, "You can try queries with testing:true, when you're ready to move to production you can POST your selector to _index to create the index which allows you to remove testing:true". That's also why I don't particularly care for the timeout approach. It's a binary threshold that a user would (maybe) meet after some unknown amount of time after they falsely believe their app is working correctly. The feedback is "Everything is fine until it isn't". Consider an app that's been working for a week or a month or more that suddenly starts throwing timeouts for a query. From the user's perspective the database broke because the query that used to work fine no longer does. And then there's the follow on question on how that timeout might instruct the user that they need an index, and that the fix may be as easy as POSTing their selector to the _index endpoint. Sure Google would most likely have the answer if our docs are good enough, but by that point the developer is probably already experiencing downtime if their app is live which means they're frantically trying to fix the thing. From my point of view, a few road blocks that guide developers towards the correct usage early on would be better than letting them get to the adrenaline fueled expletive fountain of downtime.
