You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Robert Kowalski <ro...@kowalski.gd> on 2016/01/04 13:27:34 UTC
[POC] Mango Catch All Selector
Hi list,
I hope you had awesome holidays!
The whole holidays I thought about an idea I had and today I
implemented a prototype which still has some bugs and isn't complete
yet.
I want to find out if there is general interest and if it would be
worth to spend more time.
The problem I am trying to solve is that I usually have a hard time
explaining people how views work. Now we got Mango and I can just say:
we use a syntax similar to MongoDB's query language _but you have to
create an index before you can use it_.
At this point I usually look into sad, big eyes because no one
understands why they have to create an index first and I feel there is
another entry barrier for newcomers. If trying anyway given they have
decided for CouchDB the user gets a error back: "no index available
for this selector".
The idea of this patch is to just fallback on the "give me all docs
and i filter afterwards"-trick that people usually use (if they know
it) when they just want to test something, without creating an index
which can take time for creation and requires further knowledge.
Additionally the user is warned that they can create an index to make
the queries faster.
What do you think? Is that something worth to work on further? The PR
is at https://github.com/apache/couchdb-mango/pull/27
You can test it with basic queries on a database which does not have
indexes for the fields you want to query created yet.
Best,
Robert :)
Re: [POC] Mango Catch All Selector
Posted by Garren Smith <ga...@apache.org>.
Hi All,
I really like the idea of returning an error message about it being slow along with a helpful url. I don’t really like the idea of a `slow` or `developer` flag for the actual query, I think that will add some confusion.
Cheers
Garren
> On 11 Jan 2016, at 8:55 PM, Tony Sun <to...@gmail.com> wrote:
>
> Hi Robert,
>
> Building upon what others have stated above, what do you think about
> the following:
>
> 1) Let the user query without creating an index
> 2) Return an error message with a new url that has
> "slow/no_index/developer":true appended at the end. The message clearly
> explains that this query will be slow, and that creating an index will be
> more efficient. However, he or she can continue. The error message will
> then have a link to point to our documentation.
> 3) In Fauxton, there is a checkbox or button that also appends the
> "slow/no_index/developer":true to the _find url. If the user clicks it,
> then the same message pops up to notify the user.
>
>
>
> Tony
>
>
>
> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <wi...@gmail.com>
> wrote:
>
>> Just wanted to chime in here as a user - I've run into similar
>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>> where stuff I was working on went smoothly in dev, but stopped once
>> real load was pushed through it (thankfully for me, that was in
>> testing, rather than released to customers).
>>
>> It's a frustrating experience, and I don't think that a reputation for
>> "works until you cross a threshold, and then it doesn't, but only in
>> production" is a good thing to move towards.
>>
>> Perhaps something like adding a key to the returned data along the
>> lines of "_slow_warning": "This query is going to be slow on large
>> data sets. See http://..." in addition to the ?slow_warning=true query
>> param (note that I'm calling it "slow_warning" in both places only to
>> increase discoverability; without the url param, the no-index query
>> wouldn't work at all). Bikeshed the name as needed.
>>
>> I'd like to see a lot more URLs in CouchDB error messages in general,
>> actually - I would find it very useful when trying to determine what's
>> going wrong to have a URL right there in the logs that I can get more
>> information from.
>>
>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wo...@apache.org> wrote:
>>> Hi Robert,
>>>
>>> I've been thinking about this one for the week or so, and I have a
>>> simple suggestion:
>>>
>>> Add the query parameter slow=true to enable this behaviour.
>>>
>>> This meets all the original requirements:
>>>
>>> 1. It is not default behaviour
>>> 2. You can grep the log files for the word 'slow' and find evidence
>>> 3. There is a shorthand, simple way to enable the behaviour
>>> 4. Any self-respecting developer will try to remove slow=true, find
>>> a break, and be forced to learn about indexes
>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>
>>> All the best,
>>> Joan
>>>
>>> ----- Original Message -----
>>>> From: "William Edney" <be...@technicalpursuit.com>
>>>> To: dev@couchdb.apache.org
>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>
>>>> Hi Robert -
>>>>
>>>> As a builder of UI, API and library code who has also done developer
>>>> training on a variety of technologies, one simple fix might be go
>>>> ahead and
>>>> not require indexes to be built, but then to put a big NOTE at the
>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>> is
>>>> such a piece of documentation) that states: "Note that the examples
>>>> in this
>>>> document do not require you to build an index, but for performance
>>>> reasons
>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more information
>>>> about
>>>> how to do that" (or some such verbiage).
>>>>
>>>> My 2 cents.
>>>>
>>>> Cheers,
>>>>
>>>> - Bill
>>>>
>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd>
>>>> wrote:
>>>>
>>>>> Hi list,
>>>>>
>>>>> At the end of the mail I would like to invite the other folks from
>>>>> the
>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>> UIs)
>>>>> to chime in again with their opinions. So all people one the ML,
>>>>> the
>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>
>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>> errors which are hard to debug and support.
>>>>>
>>>>> I added some thoughts to the other points you made:
>>>>>
>>>>>> a) know that the slow queries logs exist,
>>>>>
>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>> get all the log messages into your terminal. It was quite handy in
>>>>> general for all kind of debugging. That the logs are not displayed
>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>> The
>>>>> problem does occur with all kinds of log message we produce in
>>>>> CouchDB
>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>
>>>>>
>>>>>> 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".
>>>>>
>>>>> I really like the migration path you mentioned here with the API to
>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>> absolute newcomers, people that you want to play around before they
>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>> index
>>>>> topic from the beginning to the querying.
>>>>>
>>>>> When I throw too much things to learn on people (which may not
>>>>> have
>>>>> used a database before), most people get discouraged and does not
>>>>> take
>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>> "I
>>>>> have not enough time", "product XY is easier to use".
>>>>>
>>>>> I would argue that newcomers to a database will launch a high
>>>>> traffic,
>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>> the
>>>>> day where they learn how to query the data and put data into the
>>>>> database. Even for scenarios where people have a running high
>>>>> traffic
>>>>> system, and have used other databases at a medium to large scale I
>>>>> would expect given they migrate to Couch, that they run both
>>>>> systems
>>>>> in parallel for the first time in order to fix the issues that
>>>>> occur
>>>>> during a migration.
>>>>>
>>>>> I think we we share the same goal (getting beginners started
>>>>> quickly)
>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>> required knowledge to run a production system right from the very
>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>> cognitive
>>>>> load required to get the very first basic results, e.g. in a
>>>>> university class setting - or junior developers on their "casual
>>>>> friday 20% time". My big hope is, once those folks build high
>>>>> traffic
>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>> they
>>>>> start to learn more about CouchDB in order to run it in a system
>>>>> with
>>>>> more than a few thousand documents.
>>>>>
>>>>>
>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>> different. I also think this discussion still makes progress, but I
>>>>> am
>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>> and
>>>>> I would like to invite the other folks from the mailing list that
>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>> again
>>>>> with their opinions - of course I'm also looking forward to your
>>>>> answer :)
>>>>>
>>>>> Best,
>>>>> Robert :)
>>>>>
>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>> <pa...@gmail.com>
>>>>> wrote:
>>>>>>>> - 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.
>>>>>
>>>>
>>
Re: [POC] Mango Catch All Selector
Posted by Garren Smith <ga...@apache.org>.
Hi Robert,
The demo looks great. I don’t think I can take credit for the warning response. Someone else thought of that.
But I like where this is heading, it makes a lot of sense. I think this allows users to get started really quickly.
Cheers
Garren
> On 18 Jan 2016, at 1:16 AM, Robert Kowalski <ro...@kowalski.gd> wrote:
>
> Heya,
>
> thanks again for all the feedback! I built a prototype and added a demo video!
>
>> I think the current design constraint around text is a good one, and I'm
>> unconvinced including English text is a good direction.
>>
>> If you want to take this direction, including a URL to our documentation
>> instead (which *is* internationalized) is probably a better way to go,
>> something like:
>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
>
> I really like this idea! I thought long about it and I think it grows
> the scope of the current task. Right now all strings CouchDB returns
> to the user are written in English. The current message that no index
> exists is also in english. Sadly our documentation is not
> internationalised yet - afaik no language has a complete translation
> and the translations are not available as a website or in any other
> public form. I stopped translating to German myself as the promised
> integration into the doc build was never finished in ~1.5 years. For
> the specific task right now I would like to keep the scope as small as
> possible. This does not mean that I would stand in the way if folks
> want to add i18n to the project and its sub-projects and have the
> tooling and time to maintain it.
>
>
> Because a prototype speaks more than 1000 posts I hacked a prototype
> which includes the warning that was proposed by Garren. You can check
> it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
> the video: https://cloudup.com/cEnbWqbX5Y7
>
> What do you think?
>
> On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> On 13 Jan 2016, at 23:41, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> Warning: If we start using English text in a response such as this, we'll
>>> need to start externalising strings and internationalising them. We've never
>>> had to do this before because our API is, in general, terse and relies on
>>> HTTP status codes to indicate when something has gone wrong.
>>>
>>> I think the current design constraint around text is a good one, and I'm
>>> unconvinced including English text is a good direction.
>>>
>>> If you want to take this direction, including a URL to our documentation
>>> instead (which *is* internationalized) is probably a better way to go,
>>> something like:
>>>
>>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
>>
>> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
>> something like this!
>>
>> Great discussion everyone. I like how we are all making this idea better together :)
>>
>> Best
>> Jan
>> --
>>
>>
>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Robert Kowalski" <ro...@kowalski.gd>
>>> To: dev@couchdb.apache.org
>>> Sent: Wednesday, January 13, 2016 2:47:27 PM
>>> Subject: Re: [POC] Mango Catch All Selector
>>>
>>> Hi Garren,
>>>
>>> what would selector: null do? Return all docs?
>>>
>>> Where in the answer from CouchDB would be the warning? Next to the
>>> resultset, like
>>>
>>> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
>>> better performance"}] ?
>>>
>>> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
>>>
>>>> Hi Robert,
>>>>
>>>> I think you miss understood me, I don’t want it to be a different endpoint.
>>>> I just don’t want a user to have to do queries like this find({slow:
>>>> true}). I want them to be able to do a query e.g. find({}) or
>>>> find({selector: null}) and then get back the results along with a warning
>>>> message telling them that this query would be slow in production.
>>>> The lower the barrier for entry here the better. I know we want to protect
>>>> our users for when they go to production, but forcing them to add a slow:
>>>> true flag won’t help. It will still require them to read the docs a lot
>>>> more than most people are willing to on a first attempt of something new.
>>>>
>>>> Cheers
>>>> Garren
>>>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
>>>> <javascript:;>> wrote:
>>>>>
>>>>> thank you all for your feedback!
>>>>>
>>>>> i like the idea of the error message with a new url.
>>>>>
>>>>> i agree with garren that it should be a separate endpoint. it takes
>>>>> some complexity off when explaining each endpoint.
>>>>>
>>>>> maybe: `/_find_slow`?
>>>>>
>>>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
>>>> <javascript:;>> wrote:
>>>>>>
>>>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
>>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> Building upon what others have stated above, what do you think about
>>>>>>> the following:
>>>>>>>
>>>>>>> 1) Let the user query without creating an index
>>>>>>> 2) Return an error message with a new url that has
>>>>>>> "slow/no_index/developer":true appended at the end. The message clearly
>>>>>>> explains that this query will be slow, and that creating an index will
>>>> be
>>>>>>> more efficient. However, he or she can continue. The error message will
>>>>>>> then have a link to point to our documentation.
>>>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
>>>>>>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>>>>>>> then the same message pops up to notify the user.
>>>>>>
>>>>>>
>>>>>> I like this!
>>>>>>
>>>>>>
>>>>>> Jan
>>>>>> --
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Tony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
>>>> wickedgrey@gmail.com <javascript:;>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Just wanted to chime in here as a user - I've run into similar
>>>>>>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>>>>>>> where stuff I was working on went smoothly in dev, but stopped once
>>>>>>>> real load was pushed through it (thankfully for me, that was in
>>>>>>>> testing, rather than released to customers).
>>>>>>>>
>>>>>>>> It's a frustrating experience, and I don't think that a reputation for
>>>>>>>> "works until you cross a threshold, and then it doesn't, but only in
>>>>>>>> production" is a good thing to move towards.
>>>>>>>>
>>>>>>>> Perhaps something like adding a key to the returned data along the
>>>>>>>> lines of "_slow_warning": "This query is going to be slow on large
>>>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
>>>> query
>>>>>>>> param (note that I'm calling it "slow_warning" in both places only to
>>>>>>>> increase discoverability; without the url param, the no-index query
>>>>>>>> wouldn't work at all). Bikeshed the name as needed.
>>>>>>>>
>>>>>>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>>>>>>> actually - I would find it very useful when trying to determine what's
>>>>>>>> going wrong to have a URL right there in the logs that I can get more
>>>>>>>> information from.
>>>>>>>>
>>>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
>>>> <javascript:;>> wrote:
>>>>>>>>> Hi Robert,
>>>>>>>>>
>>>>>>>>> I've been thinking about this one for the week or so, and I have a
>>>>>>>>> simple suggestion:
>>>>>>>>>
>>>>>>>>> Add the query parameter slow=true to enable this behaviour.
>>>>>>>>>
>>>>>>>>> This meets all the original requirements:
>>>>>>>>>
>>>>>>>>> 1. It is not default behaviour
>>>>>>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>>>>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>>>>>>> a break, and be forced to learn about indexes
>>>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>>>>>>
>>>>>>>>> All the best,
>>>>>>>>> Joan
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
>>>>>>>>>> To: dev@couchdb.apache.org <javascript:;>
>>>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>>>>>>
>>>>>>>>>> Hi Robert -
>>>>>>>>>>
>>>>>>>>>> As a builder of UI, API and library code who has also done developer
>>>>>>>>>> training on a variety of technologies, one simple fix might be go
>>>>>>>>>> ahead and
>>>>>>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>>>>>>> is
>>>>>>>>>> such a piece of documentation) that states: "Note that the examples
>>>>>>>>>> in this
>>>>>>>>>> document do not require you to build an index, but for performance
>>>>>>>>>> reasons
>>>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
>>>> information
>>>>>>>>>> about
>>>>>>>>>> how to do that" (or some such verbiage).
>>>>>>>>>>
>>>>>>>>>> My 2 cents.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> - Bill
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
>>>> <javascript:;>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi list,
>>>>>>>>>>>
>>>>>>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>>>>>>> the
>>>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>>>>>>> UIs)
>>>>>>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>>>>>>> the
>>>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>>>>>>
>>>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>>>>>>> errors which are hard to debug and support.
>>>>>>>>>>>
>>>>>>>>>>> I added some thoughts to the other points you made:
>>>>>>>>>>>
>>>>>>>>>>>> a) know that the slow queries logs exist,
>>>>>>>>>>>
>>>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>>>>>>> The
>>>>>>>>>>> problem does occur with all kinds of log message we produce in
>>>>>>>>>>> CouchDB
>>>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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".
>>>>>>>>>>>
>>>>>>>>>>> I really like the migration path you mentioned here with the API to
>>>>>>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>>>>>>> absolute newcomers, people that you want to play around before they
>>>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>>>>>>> index
>>>>>>>>>>> topic from the beginning to the querying.
>>>>>>>>>>>
>>>>>>>>>>> When I throw too much things to learn on people (which may not
>>>>>>>>>>> have
>>>>>>>>>>> used a database before), most people get discouraged and does not
>>>>>>>>>>> take
>>>>>>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>>>>>>> "I
>>>>>>>>>>> have not enough time", "product XY is easier to use".
>>>>>>>>>>>
>>>>>>>>>>> I would argue that newcomers to a database will launch a high
>>>>>>>>>>> traffic,
>>>>>>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>>>>>>> the
>>>>>>>>>>> day where they learn how to query the data and put data into the
>>>>>>>>>>> database. Even for scenarios where people have a running high
>>>>>>>>>>> traffic
>>>>>>>>>>> system, and have used other databases at a medium to large scale I
>>>>>>>>>>> would expect given they migrate to Couch, that they run both
>>>>>>>>>>> systems
>>>>>>>>>>> in parallel for the first time in order to fix the issues that
>>>>>>>>>>> occur
>>>>>>>>>>> during a migration.
>>>>>>>>>>>
>>>>>>>>>>> I think we we share the same goal (getting beginners started
>>>>>>>>>>> quickly)
>>>>>>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>>>>>>> required knowledge to run a production system right from the very
>>>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>>>>>>> cognitive
>>>>>>>>>>> load required to get the very first basic results, e.g. in a
>>>>>>>>>>> university class setting - or junior developers on their "casual
>>>>>>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>>>>>>> traffic
>>>>>>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>>>>>>> they
>>>>>>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>>>>>>> with
>>>>>>>>>>> more than a few thousand documents.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>>>>>>> different. I also think this discussion still makes progress, but I
>>>>>>>>>>> am
>>>>>>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>>>>>>> and
>>>>>>>>>>> I would like to invite the other folks from the mailing list that
>>>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>>>>>>> again
>>>>>>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>>>>>>> answer :)
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Robert :)
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> - 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>
Re: [POC] Mango Catch All Selector
Posted by William Edney <be...@technicalpursuit.com>.
This is awesome. I, for one, can tell you that we'll be using it.
Thank you Robert!
Cheers,
- Bill
On Fri, Feb 12, 2016 at 7:27 PM, Robert Kowalski <ro...@kowalski.gd> wrote:
> the new behaviour for mango landed this week on master, i hope you all
> enjoy it!
>
> please report any bugs, problems, feedback and also praise :)
>
> On Mon, Jan 18, 2016 at 11:59 AM, Jan Lehnardt <ja...@apache.org> wrote:
> > This is awesome: +1
> >
> >
> >> On 18 Jan 2016, at 00:16, Robert Kowalski <ro...@kowalski.gd> wrote:
> >>
> >> Heya,
> >>
> >> thanks again for all the feedback! I built a prototype and added a demo
> video!
> >>
> >>> I think the current design constraint around text is a good one, and
> I'm
> >>> unconvinced including English text is a good direction.
> >>>
> >>> If you want to take this direction, including a URL to our
> documentation
> >>> instead (which *is* internationalized) is probably a better way to go,
> >>> something like:
> >>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
> >>
> >> I really like this idea! I thought long about it and I think it grows
> >> the scope of the current task. Right now all strings CouchDB returns
> >> to the user are written in English. The current message that no index
> >> exists is also in english. Sadly our documentation is not
> >> internationalised yet - afaik no language has a complete translation
> >> and the translations are not available as a website or in any other
> >> public form. I stopped translating to German myself as the promised
> >> integration into the doc build was never finished in ~1.5 years. For
> >> the specific task right now I would like to keep the scope as small as
> >> possible. This does not mean that I would stand in the way if folks
> >> want to add i18n to the project and its sub-projects and have the
> >> tooling and time to maintain it.
> >>
> >>
> >> Because a prototype speaks more than 1000 posts I hacked a prototype
> >> which includes the warning that was proposed by Garren. You can check
> >> it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
> >> the video: https://cloudup.com/cEnbWqbX5Y7
> >>
> >> What do you think?
> >>
> >> On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>>
> >>>> On 13 Jan 2016, at 23:41, Joan Touzet <wo...@apache.org> wrote:
> >>>>
> >>>> Warning: If we start using English text in a response such as this,
> we'll
> >>>> need to start externalising strings and internationalising them.
> We've never
> >>>> had to do this before because our API is, in general, terse and
> relies on
> >>>> HTTP status codes to indicate when something has gone wrong.
> >>>>
> >>>> I think the current design constraint around text is a good one, and
> I'm
> >>>> unconvinced including English text is a good direction.
> >>>>
> >>>> If you want to take this direction, including a URL to our
> documentation
> >>>> instead (which *is* internationalized) is probably a better way to go,
> >>>> something like:
> >>>>
> >>>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
> >>>
> >>> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
> >>> something like this!
> >>>
> >>> Great discussion everyone. I like how we are all making this idea
> better together :)
> >>>
> >>> Best
> >>> Jan
> >>> --
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Robert Kowalski" <ro...@kowalski.gd>
> >>>> To: dev@couchdb.apache.org
> >>>> Sent: Wednesday, January 13, 2016 2:47:27 PM
> >>>> Subject: Re: [POC] Mango Catch All Selector
> >>>>
> >>>> Hi Garren,
> >>>>
> >>>> what would selector: null do? Return all docs?
> >>>>
> >>>> Where in the answer from CouchDB would be the warning? Next to the
> >>>> resultset, like
> >>>>
> >>>> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an
> index for
> >>>> better performance"}] ?
> >>>>
> >>>> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
> >>>>
> >>>>> Hi Robert,
> >>>>>
> >>>>> I think you miss understood me, I don’t want it to be a different
> endpoint.
> >>>>> I just don’t want a user to have to do queries like this find({slow:
> >>>>> true}). I want them to be able to do a query e.g. find({}) or
> >>>>> find({selector: null}) and then get back the results along with a
> warning
> >>>>> message telling them that this query would be slow in production.
> >>>>> The lower the barrier for entry here the better. I know we want to
> protect
> >>>>> our users for when they go to production, but forcing them to add a
> slow:
> >>>>> true flag won’t help. It will still require them to read the docs a
> lot
> >>>>> more than most people are willing to on a first attempt of something
> new.
> >>>>>
> >>>>> Cheers
> >>>>> Garren
> >>>>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
> >>>>> <javascript:;>> wrote:
> >>>>>>
> >>>>>> thank you all for your feedback!
> >>>>>>
> >>>>>> i like the idea of the error message with a new url.
> >>>>>>
> >>>>>> i agree with garren that it should be a separate endpoint. it takes
> >>>>>> some complexity off when explaining each endpoint.
> >>>>>>
> >>>>>> maybe: `/_find_slow`?
> >>>>>>
> >>>>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
> >>>>> <javascript:;>> wrote:
> >>>>>>>
> >>>>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
> >>>>> <javascript:;>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Robert,
> >>>>>>>>
> >>>>>>>> Building upon what others have stated above, what do you think
> about
> >>>>>>>> the following:
> >>>>>>>>
> >>>>>>>> 1) Let the user query without creating an index
> >>>>>>>> 2) Return an error message with a new url that has
> >>>>>>>> "slow/no_index/developer":true appended at the end. The message
> clearly
> >>>>>>>> explains that this query will be slow, and that creating an index
> will
> >>>>> be
> >>>>>>>> more efficient. However, he or she can continue. The error
> message will
> >>>>>>>> then have a link to point to our documentation.
> >>>>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
> >>>>>>>> "slow/no_index/developer":true to the _find url. If the user
> clicks it,
> >>>>>>>> then the same message pops up to notify the user.
> >>>>>>>
> >>>>>>>
> >>>>>>> I like this!
> >>>>>>>
> >>>>>>>
> >>>>>>> Jan
> >>>>>>> --
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Tony
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
> >>>>> wickedgrey@gmail.com <javascript:;>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Just wanted to chime in here as a user - I've run into similar
> >>>>>>>>> behavior from CouchDB with the reduce-not-reducing-enough
> heuristic,
> >>>>>>>>> where stuff I was working on went smoothly in dev, but stopped
> once
> >>>>>>>>> real load was pushed through it (thankfully for me, that was in
> >>>>>>>>> testing, rather than released to customers).
> >>>>>>>>>
> >>>>>>>>> It's a frustrating experience, and I don't think that a
> reputation for
> >>>>>>>>> "works until you cross a threshold, and then it doesn't, but
> only in
> >>>>>>>>> production" is a good thing to move towards.
> >>>>>>>>>
> >>>>>>>>> Perhaps something like adding a key to the returned data along
> the
> >>>>>>>>> lines of "_slow_warning": "This query is going to be slow on
> large
> >>>>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
> >>>>> query
> >>>>>>>>> param (note that I'm calling it "slow_warning" in both places
> only to
> >>>>>>>>> increase discoverability; without the url param, the no-index
> query
> >>>>>>>>> wouldn't work at all). Bikeshed the name as needed.
> >>>>>>>>>
> >>>>>>>>> I'd like to see a lot more URLs in CouchDB error messages in
> general,
> >>>>>>>>> actually - I would find it very useful when trying to determine
> what's
> >>>>>>>>> going wrong to have a URL right there in the logs that I can get
> more
> >>>>>>>>> information from.
> >>>>>>>>>
> >>>>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
> >>>>> <javascript:;>> wrote:
> >>>>>>>>>> Hi Robert,
> >>>>>>>>>>
> >>>>>>>>>> I've been thinking about this one for the week or so, and I
> have a
> >>>>>>>>>> simple suggestion:
> >>>>>>>>>>
> >>>>>>>>>> Add the query parameter slow=true to enable this behaviour.
> >>>>>>>>>>
> >>>>>>>>>> This meets all the original requirements:
> >>>>>>>>>>
> >>>>>>>>>> 1. It is not default behaviour
> >>>>>>>>>> 2. You can grep the log files for the word 'slow' and find
> evidence
> >>>>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
> >>>>>>>>>> 4. Any self-respecting developer will try to remove slow=true,
> find
> >>>>>>>>>> a break, and be forced to learn about indexes
> >>>>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
> >>>>>>>>>>
> >>>>>>>>>> All the best,
> >>>>>>>>>> Joan
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com
> <javascript:;>>
> >>>>>>>>>>> To: dev@couchdb.apache.org <javascript:;>
> >>>>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
> >>>>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Robert -
> >>>>>>>>>>>
> >>>>>>>>>>> As a builder of UI, API and library code who has also done
> developer
> >>>>>>>>>>> training on a variety of technologies, one simple fix might be
> go
> >>>>>>>>>>> ahead and
> >>>>>>>>>>> not require indexes to be built, but then to put a big NOTE at
> the
> >>>>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume
> there
> >>>>>>>>>>> is
> >>>>>>>>>>> such a piece of documentation) that states: "Note that the
> examples
> >>>>>>>>>>> in this
> >>>>>>>>>>> document do not require you to build an index, but for
> performance
> >>>>>>>>>>> reasons
> >>>>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
> >>>>> information
> >>>>>>>>>>> about
> >>>>>>>>>>> how to do that" (or some such verbiage).
> >>>>>>>>>>>
> >>>>>>>>>>> My 2 cents.
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>>
> >>>>>>>>>>> - Bill
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <
> rok@kowalski.gd
> >>>>> <javascript:;>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi list,
> >>>>>>>>>>>>
> >>>>>>>>>>>> At the end of the mail I would like to invite the other folks
> from
> >>>>>>>>>>>> the
> >>>>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or
> even
> >>>>>>>>>>>> UIs)
> >>>>>>>>>>>> to chime in again with their opinions. So all people one the
> ML,
> >>>>>>>>>>>> the
> >>>>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very
> unpleasant
> >>>>>>>>>>>> errors which are hard to debug and support.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I added some thoughts to the other points you made:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> a) know that the slow queries logs exist,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
> >>>>>>>>>>>> straightforward. As a developer you would spin up a CouchDB
> and you
> >>>>>>>>>>>> get all the log messages into your terminal. It was quite
> handy in
> >>>>>>>>>>>> general for all kind of debugging. That the logs are not
> displayed
> >>>>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x
> problem.
> >>>>>>>>>>>> The
> >>>>>>>>>>>> problem does occur with all kinds of log message we produce in
> >>>>>>>>>>>> CouchDB
> >>>>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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".
> >>>>>>>>>>>>
> >>>>>>>>>>>> I really like the migration path you mentioned here with the
> API to
> >>>>>>>>>>>> create indexes. I am worried to have a too high entry barrier
> for
> >>>>>>>>>>>> absolute newcomers, people that you want to play around
> before they
> >>>>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
> >>>>>>>>>>>> index
> >>>>>>>>>>>> topic from the beginning to the querying.
> >>>>>>>>>>>>
> >>>>>>>>>>>> When I throw too much things to learn on people (which may
> not
> >>>>>>>>>>>> have
> >>>>>>>>>>>> used a database before), most people get discouraged and does
> not
> >>>>>>>>>>>> take
> >>>>>>>>>>>> a look. The usual things they feel or say are : "too
> complicated",
> >>>>>>>>>>>> "I
> >>>>>>>>>>>> have not enough time", "product XY is easier to use".
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would argue that newcomers to a database will launch a high
> >>>>>>>>>>>> traffic,
> >>>>>>>>>>>> multi-gigabyte product with the database from day one. Day
> one is
> >>>>>>>>>>>> the
> >>>>>>>>>>>> day where they learn how to query the data and put data into
> the
> >>>>>>>>>>>> database. Even for scenarios where people have a running high
> >>>>>>>>>>>> traffic
> >>>>>>>>>>>> system, and have used other databases at a medium to large
> scale I
> >>>>>>>>>>>> would expect given they migrate to Couch, that they run both
> >>>>>>>>>>>> systems
> >>>>>>>>>>>> in parallel for the first time in order to fix the issues that
> >>>>>>>>>>>> occur
> >>>>>>>>>>>> during a migration.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think we we share the same goal (getting beginners started
> >>>>>>>>>>>> quickly)
> >>>>>>>>>>>> and the cool thing about your suggestion is that everyone
> gets the
> >>>>>>>>>>>> required knowledge to run a production system right from the
> very
> >>>>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
> >>>>>>>>>>>> cognitive
> >>>>>>>>>>>> load required to get the very first basic results, e.g. in a
> >>>>>>>>>>>> university class setting - or junior developers on their
> "casual
> >>>>>>>>>>>> friday 20% time". My big hope is, once those folks build high
> >>>>>>>>>>>> traffic
> >>>>>>>>>>>> systems, they remember how easy the usage of CouchDB was and
> that
> >>>>>>>>>>>> they
> >>>>>>>>>>>> start to learn more about CouchDB in order to run it in a
> system
> >>>>>>>>>>>> with
> >>>>>>>>>>>> more than a few thousand documents.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> For us both I think the "what" is clear, but the "how" is a
> bit
> >>>>>>>>>>>> different. I also think this discussion still makes progress,
> but I
> >>>>>>>>>>>> am
> >>>>>>>>>>>> afraid it could stall. I see that we both have very good
> rudiments
> >>>>>>>>>>>> and
> >>>>>>>>>>>> I would like to invite the other folks from the mailing list
> that
> >>>>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime
> in
> >>>>>>>>>>>> again
> >>>>>>>>>>>> with their opinions - of course I'm also looking forward to
> your
> >>>>>>>>>>>> answer :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best,
> >>>>>>>>>>>> Robert :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
> >>>>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> - 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >
>
Re: [POC] Mango Catch All Selector
Posted by Garren Smith <ga...@apache.org>.
Awesome. Thanks Robert
On Saturday, 13 February 2016, Robert Kowalski <ro...@kowalski.gd> wrote:
> the new behaviour for mango landed this week on master, i hope you all
> enjoy it!
>
> please report any bugs, problems, feedback and also praise :)
>
> On Mon, Jan 18, 2016 at 11:59 AM, Jan Lehnardt <jan@apache.org
> <javascript:;>> wrote:
> > This is awesome: +1
> >
> >
> >> On 18 Jan 2016, at 00:16, Robert Kowalski <rok@kowalski.gd
> <javascript:;>> wrote:
> >>
> >> Heya,
> >>
> >> thanks again for all the feedback! I built a prototype and added a demo
> video!
> >>
> >>> I think the current design constraint around text is a good one, and
> I'm
> >>> unconvinced including English text is a good direction.
> >>>
> >>> If you want to take this direction, including a URL to our
> documentation
> >>> instead (which *is* internationalized) is probably a better way to go,
> >>> something like:
> >>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
> >>
> >> I really like this idea! I thought long about it and I think it grows
> >> the scope of the current task. Right now all strings CouchDB returns
> >> to the user are written in English. The current message that no index
> >> exists is also in english. Sadly our documentation is not
> >> internationalised yet - afaik no language has a complete translation
> >> and the translations are not available as a website or in any other
> >> public form. I stopped translating to German myself as the promised
> >> integration into the doc build was never finished in ~1.5 years. For
> >> the specific task right now I would like to keep the scope as small as
> >> possible. This does not mean that I would stand in the way if folks
> >> want to add i18n to the project and its sub-projects and have the
> >> tooling and time to maintain it.
> >>
> >>
> >> Because a prototype speaks more than 1000 posts I hacked a prototype
> >> which includes the warning that was proposed by Garren. You can check
> >> it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
> >> the video: https://cloudup.com/cEnbWqbX5Y7
> >>
> >> What do you think?
> >>
> >> On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <jan@apache.org
> <javascript:;>> wrote:
> >>>
> >>>> On 13 Jan 2016, at 23:41, Joan Touzet <wohali@apache.org
> <javascript:;>> wrote:
> >>>>
> >>>> Warning: If we start using English text in a response such as this,
> we'll
> >>>> need to start externalising strings and internationalising them.
> We've never
> >>>> had to do this before because our API is, in general, terse and
> relies on
> >>>> HTTP status codes to indicate when something has gone wrong.
> >>>>
> >>>> I think the current design constraint around text is a good one, and
> I'm
> >>>> unconvinced including English text is a good direction.
> >>>>
> >>>> If you want to take this direction, including a URL to our
> documentation
> >>>> instead (which *is* internationalized) is probably a better way to go,
> >>>> something like:
> >>>>
> >>>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
> >>>
> >>> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
> >>> something like this!
> >>>
> >>> Great discussion everyone. I like how we are all making this idea
> better together :)
> >>>
> >>> Best
> >>> Jan
> >>> --
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Robert Kowalski" <rok@kowalski.gd <javascript:;>>
> >>>> To: dev@couchdb.apache.org <javascript:;>
> >>>> Sent: Wednesday, January 13, 2016 2:47:27 PM
> >>>> Subject: Re: [POC] Mango Catch All Selector
> >>>>
> >>>> Hi Garren,
> >>>>
> >>>> what would selector: null do? Return all docs?
> >>>>
> >>>> Where in the answer from CouchDB would be the warning? Next to the
> >>>> resultset, like
> >>>>
> >>>> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an
> index for
> >>>> better performance"}] ?
> >>>>
> >>>> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
> >>>>
> >>>>> Hi Robert,
> >>>>>
> >>>>> I think you miss understood me, I don’t want it to be a different
> endpoint.
> >>>>> I just don’t want a user to have to do queries like this find({slow:
> >>>>> true}). I want them to be able to do a query e.g. find({}) or
> >>>>> find({selector: null}) and then get back the results along with a
> warning
> >>>>> message telling them that this query would be slow in production.
> >>>>> The lower the barrier for entry here the better. I know we want to
> protect
> >>>>> our users for when they go to production, but forcing them to add a
> slow:
> >>>>> true flag won’t help. It will still require them to read the docs a
> lot
> >>>>> more than most people are willing to on a first attempt of something
> new.
> >>>>>
> >>>>> Cheers
> >>>>> Garren
> >>>>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
> <javascript:;>
> >>>>> <javascript:;>> wrote:
> >>>>>>
> >>>>>> thank you all for your feedback!
> >>>>>>
> >>>>>> i like the idea of the error message with a new url.
> >>>>>>
> >>>>>> i agree with garren that it should be a separate endpoint. it takes
> >>>>>> some complexity off when explaining each endpoint.
> >>>>>>
> >>>>>> maybe: `/_find_slow`?
> >>>>>>
> >>>>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
> <javascript:;>
> >>>>> <javascript:;>> wrote:
> >>>>>>>
> >>>>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
> <javascript:;>
> >>>>> <javascript:;>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Robert,
> >>>>>>>>
> >>>>>>>> Building upon what others have stated above, what do you think
> about
> >>>>>>>> the following:
> >>>>>>>>
> >>>>>>>> 1) Let the user query without creating an index
> >>>>>>>> 2) Return an error message with a new url that has
> >>>>>>>> "slow/no_index/developer":true appended at the end. The message
> clearly
> >>>>>>>> explains that this query will be slow, and that creating an index
> will
> >>>>> be
> >>>>>>>> more efficient. However, he or she can continue. The error
> message will
> >>>>>>>> then have a link to point to our documentation.
> >>>>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
> >>>>>>>> "slow/no_index/developer":true to the _find url. If the user
> clicks it,
> >>>>>>>> then the same message pops up to notify the user.
> >>>>>>>
> >>>>>>>
> >>>>>>> I like this!
> >>>>>>>
> >>>>>>>
> >>>>>>> Jan
> >>>>>>> --
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Tony
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
> >>>>> wickedgrey@gmail.com <javascript:;> <javascript:;>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Just wanted to chime in here as a user - I've run into similar
> >>>>>>>>> behavior from CouchDB with the reduce-not-reducing-enough
> heuristic,
> >>>>>>>>> where stuff I was working on went smoothly in dev, but stopped
> once
> >>>>>>>>> real load was pushed through it (thankfully for me, that was in
> >>>>>>>>> testing, rather than released to customers).
> >>>>>>>>>
> >>>>>>>>> It's a frustrating experience, and I don't think that a
> reputation for
> >>>>>>>>> "works until you cross a threshold, and then it doesn't, but
> only in
> >>>>>>>>> production" is a good thing to move towards.
> >>>>>>>>>
> >>>>>>>>> Perhaps something like adding a key to the returned data along
> the
> >>>>>>>>> lines of "_slow_warning": "This query is going to be slow on
> large
> >>>>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
> >>>>> query
> >>>>>>>>> param (note that I'm calling it "slow_warning" in both places
> only to
> >>>>>>>>> increase discoverability; without the url param, the no-index
> query
> >>>>>>>>> wouldn't work at all). Bikeshed the name as needed.
> >>>>>>>>>
> >>>>>>>>> I'd like to see a lot more URLs in CouchDB error messages in
> general,
> >>>>>>>>> actually - I would find it very useful when trying to determine
> what's
> >>>>>>>>> going wrong to have a URL right there in the logs that I can get
> more
> >>>>>>>>> information from.
> >>>>>>>>>
> >>>>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
> <javascript:;>
> >>>>> <javascript:;>> wrote:
> >>>>>>>>>> Hi Robert,
> >>>>>>>>>>
> >>>>>>>>>> I've been thinking about this one for the week or so, and I
> have a
> >>>>>>>>>> simple suggestion:
> >>>>>>>>>>
> >>>>>>>>>> Add the query parameter slow=true to enable this behaviour.
> >>>>>>>>>>
> >>>>>>>>>> This meets all the original requirements:
> >>>>>>>>>>
> >>>>>>>>>> 1. It is not default behaviour
> >>>>>>>>>> 2. You can grep the log files for the word 'slow' and find
> evidence
> >>>>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
> >>>>>>>>>> 4. Any self-respecting developer will try to remove slow=true,
> find
> >>>>>>>>>> a break, and be forced to learn about indexes
> >>>>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
> >>>>>>>>>>
> >>>>>>>>>> All the best,
> >>>>>>>>>> Joan
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com
> <javascript:;> <javascript:;>>
> >>>>>>>>>>> To: dev@couchdb.apache.org <javascript:;> <javascript:;>
> >>>>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
> >>>>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Robert -
> >>>>>>>>>>>
> >>>>>>>>>>> As a builder of UI, API and library code who has also done
> developer
> >>>>>>>>>>> training on a variety of technologies, one simple fix might be
> go
> >>>>>>>>>>> ahead and
> >>>>>>>>>>> not require indexes to be built, but then to put a big NOTE at
> the
> >>>>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume
> there
> >>>>>>>>>>> is
> >>>>>>>>>>> such a piece of documentation) that states: "Note that the
> examples
> >>>>>>>>>>> in this
> >>>>>>>>>>> document do not require you to build an index, but for
> performance
> >>>>>>>>>>> reasons
> >>>>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
> >>>>> information
> >>>>>>>>>>> about
> >>>>>>>>>>> how to do that" (or some such verbiage).
> >>>>>>>>>>>
> >>>>>>>>>>> My 2 cents.
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>>
> >>>>>>>>>>> - Bill
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <
> rok@kowalski.gd <javascript:;>
> >>>>> <javascript:;>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi list,
> >>>>>>>>>>>>
> >>>>>>>>>>>> At the end of the mail I would like to invite the other folks
> from
> >>>>>>>>>>>> the
> >>>>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or
> even
> >>>>>>>>>>>> UIs)
> >>>>>>>>>>>> to chime in again with their opinions. So all people one the
> ML,
> >>>>>>>>>>>> the
> >>>>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very
> unpleasant
> >>>>>>>>>>>> errors which are hard to debug and support.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I added some thoughts to the other points you made:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> a) know that the slow queries logs exist,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
> >>>>>>>>>>>> straightforward. As a developer you would spin up a CouchDB
> and you
> >>>>>>>>>>>> get all the log messages into your terminal. It was quite
> handy in
> >>>>>>>>>>>> general for all kind of debugging. That the logs are not
> displayed
> >>>>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x
> problem.
> >>>>>>>>>>>> The
> >>>>>>>>>>>> problem does occur with all kinds of log message we produce in
> >>>>>>>>>>>> CouchDB
> >>>>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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".
> >>>>>>>>>>>>
> >>>>>>>>>>>> I really like the migration path you mentioned here with the
> API to
> >>>>>>>>>>>> create indexes. I am worried to have a too high entry barrier
> for
> >>>>>>>>>>>> absolute newcomers, people that you want to play around
> before they
> >>>>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
> >>>>>>>>>>>> index
> >>>>>>>>>>>> topic from the beginning to the querying.
> >>>>>>>>>>>>
> >>>>>>>>>>>> When I throw too much things to learn on people (which may
> not
> >>>>>>>>>>>> have
> >>>>>>>>>>>> used a database before), most people get discouraged and does
> not
> >>>>>>>>>>>> take
> >>>>>>>>>>>> a look. The usual things they feel or say are : "too
> complicated",
> >>>>>>>>>>>> "I
> >>>>>>>>>>>> have not enough time", "product XY is easier to use".
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would argue that newcomers to a database will launch a high
> >>>>>>>>>>>> traffic,
> >>>>>>>>>>>> multi-gigabyte product with the database from day one. Day
> one is
> >>>>>>>>>>>> the
> >>>>>>>>>>>> day where they learn how to query the data and put data into
> the
> >>>>>>>>>>>> database. Even for scenarios where people have a running high
> >>>>>>>>>>>> traffic
> >>>>>>>>>>>> system, and have used other databases at a medium to large
> scale I
> >>>>>>>>>>>> would expect given they migrate to Couch, that they run both
> >>>>>>>>>>>> systems
> >>>>>>>>>>>> in parallel for the first time in order to fix the issues that
> >>>>>>>>>>>> occur
> >>>>>>>>>>>> during a migration.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think we we share the same goal (getting beginners started
> >>>>>>>>>>>> quickly)
> >>>>>>>>>>>> and the cool thing about your suggestion is that everyone
> gets the
> >>>>>>>>>>>> required knowledge to run a production system right from the
> very
> >>>>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
> >>>>>>>>>>>> cognitive
> >>>>>>>>>>>> load required to get the very first basic results, e.g. in a
> >>>>>>>>>>>> university class setting - or junior developers on their
> "casual
> >>>>>>>>>>>> friday 20% time". My big hope is, once those folks build high
> >>>>>>>>>>>> traffic
> >>>>>>>>>>>> systems, they remember how easy the usage of CouchDB was and
> that
> >>>>>>>>>>>> they
> >>>>>>>>>>>> start to learn more about CouchDB in order to run it in a
> system
> >>>>>>>>>>>> with
> >>>>>>>>>>>> more than a few thousand documents.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> For us both I think the "what" is clear, but the "how" is a
> bit
> >>>>>>>>>>>> different. I also think this discussion still makes progress,
> but I
> >>>>>>>>>>>> am
> >>>>>>>>>>>> afraid it could stall. I see that we both have very good
> rudiments
> >>>>>>>>>>>> and
> >>>>>>>>>>>> I would like to invite the other folks from the mailing list
> that
> >>>>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime
> in
> >>>>>>>>>>>> again
> >>>>>>>>>>>> with their opinions - of course I'm also looking forward to
> your
> >>>>>>>>>>>> answer :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best,
> >>>>>>>>>>>> Robert :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
> >>>>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;> <javascript:;>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> - 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.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >
>
Re: [POC] Mango Catch All Selector
Posted by Robert Kowalski <ro...@kowalski.gd>.
the new behaviour for mango landed this week on master, i hope you all enjoy it!
please report any bugs, problems, feedback and also praise :)
On Mon, Jan 18, 2016 at 11:59 AM, Jan Lehnardt <ja...@apache.org> wrote:
> This is awesome: +1
>
>
>> On 18 Jan 2016, at 00:16, Robert Kowalski <ro...@kowalski.gd> wrote:
>>
>> Heya,
>>
>> thanks again for all the feedback! I built a prototype and added a demo video!
>>
>>> I think the current design constraint around text is a good one, and I'm
>>> unconvinced including English text is a good direction.
>>>
>>> If you want to take this direction, including a URL to our documentation
>>> instead (which *is* internationalized) is probably a better way to go,
>>> something like:
>>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
>>
>> I really like this idea! I thought long about it and I think it grows
>> the scope of the current task. Right now all strings CouchDB returns
>> to the user are written in English. The current message that no index
>> exists is also in english. Sadly our documentation is not
>> internationalised yet - afaik no language has a complete translation
>> and the translations are not available as a website or in any other
>> public form. I stopped translating to German myself as the promised
>> integration into the doc build was never finished in ~1.5 years. For
>> the specific task right now I would like to keep the scope as small as
>> possible. This does not mean that I would stand in the way if folks
>> want to add i18n to the project and its sub-projects and have the
>> tooling and time to maintain it.
>>
>>
>> Because a prototype speaks more than 1000 posts I hacked a prototype
>> which includes the warning that was proposed by Garren. You can check
>> it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
>> the video: https://cloudup.com/cEnbWqbX5Y7
>>
>> What do you think?
>>
>> On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>> On 13 Jan 2016, at 23:41, Joan Touzet <wo...@apache.org> wrote:
>>>>
>>>> Warning: If we start using English text in a response such as this, we'll
>>>> need to start externalising strings and internationalising them. We've never
>>>> had to do this before because our API is, in general, terse and relies on
>>>> HTTP status codes to indicate when something has gone wrong.
>>>>
>>>> I think the current design constraint around text is a good one, and I'm
>>>> unconvinced including English text is a good direction.
>>>>
>>>> If you want to take this direction, including a URL to our documentation
>>>> instead (which *is* internationalized) is probably a better way to go,
>>>> something like:
>>>>
>>>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
>>>
>>> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
>>> something like this!
>>>
>>> Great discussion everyone. I like how we are all making this idea better together :)
>>>
>>> Best
>>> Jan
>>> --
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Robert Kowalski" <ro...@kowalski.gd>
>>>> To: dev@couchdb.apache.org
>>>> Sent: Wednesday, January 13, 2016 2:47:27 PM
>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>
>>>> Hi Garren,
>>>>
>>>> what would selector: null do? Return all docs?
>>>>
>>>> Where in the answer from CouchDB would be the warning? Next to the
>>>> resultset, like
>>>>
>>>> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
>>>> better performance"}] ?
>>>>
>>>> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
>>>>
>>>>> Hi Robert,
>>>>>
>>>>> I think you miss understood me, I don’t want it to be a different endpoint.
>>>>> I just don’t want a user to have to do queries like this find({slow:
>>>>> true}). I want them to be able to do a query e.g. find({}) or
>>>>> find({selector: null}) and then get back the results along with a warning
>>>>> message telling them that this query would be slow in production.
>>>>> The lower the barrier for entry here the better. I know we want to protect
>>>>> our users for when they go to production, but forcing them to add a slow:
>>>>> true flag won’t help. It will still require them to read the docs a lot
>>>>> more than most people are willing to on a first attempt of something new.
>>>>>
>>>>> Cheers
>>>>> Garren
>>>>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
>>>>> <javascript:;>> wrote:
>>>>>>
>>>>>> thank you all for your feedback!
>>>>>>
>>>>>> i like the idea of the error message with a new url.
>>>>>>
>>>>>> i agree with garren that it should be a separate endpoint. it takes
>>>>>> some complexity off when explaining each endpoint.
>>>>>>
>>>>>> maybe: `/_find_slow`?
>>>>>>
>>>>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
>>>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
>>>>> <javascript:;>> wrote:
>>>>>>>>
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> Building upon what others have stated above, what do you think about
>>>>>>>> the following:
>>>>>>>>
>>>>>>>> 1) Let the user query without creating an index
>>>>>>>> 2) Return an error message with a new url that has
>>>>>>>> "slow/no_index/developer":true appended at the end. The message clearly
>>>>>>>> explains that this query will be slow, and that creating an index will
>>>>> be
>>>>>>>> more efficient. However, he or she can continue. The error message will
>>>>>>>> then have a link to point to our documentation.
>>>>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
>>>>>>>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>>>>>>>> then the same message pops up to notify the user.
>>>>>>>
>>>>>>>
>>>>>>> I like this!
>>>>>>>
>>>>>>>
>>>>>>> Jan
>>>>>>> --
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Tony
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
>>>>> wickedgrey@gmail.com <javascript:;>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Just wanted to chime in here as a user - I've run into similar
>>>>>>>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>>>>>>>> where stuff I was working on went smoothly in dev, but stopped once
>>>>>>>>> real load was pushed through it (thankfully for me, that was in
>>>>>>>>> testing, rather than released to customers).
>>>>>>>>>
>>>>>>>>> It's a frustrating experience, and I don't think that a reputation for
>>>>>>>>> "works until you cross a threshold, and then it doesn't, but only in
>>>>>>>>> production" is a good thing to move towards.
>>>>>>>>>
>>>>>>>>> Perhaps something like adding a key to the returned data along the
>>>>>>>>> lines of "_slow_warning": "This query is going to be slow on large
>>>>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
>>>>> query
>>>>>>>>> param (note that I'm calling it "slow_warning" in both places only to
>>>>>>>>> increase discoverability; without the url param, the no-index query
>>>>>>>>> wouldn't work at all). Bikeshed the name as needed.
>>>>>>>>>
>>>>>>>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>>>>>>>> actually - I would find it very useful when trying to determine what's
>>>>>>>>> going wrong to have a URL right there in the logs that I can get more
>>>>>>>>> information from.
>>>>>>>>>
>>>>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
>>>>> <javascript:;>> wrote:
>>>>>>>>>> Hi Robert,
>>>>>>>>>>
>>>>>>>>>> I've been thinking about this one for the week or so, and I have a
>>>>>>>>>> simple suggestion:
>>>>>>>>>>
>>>>>>>>>> Add the query parameter slow=true to enable this behaviour.
>>>>>>>>>>
>>>>>>>>>> This meets all the original requirements:
>>>>>>>>>>
>>>>>>>>>> 1. It is not default behaviour
>>>>>>>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>>>>>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>>>>>>>> a break, and be forced to learn about indexes
>>>>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>>>>>>>
>>>>>>>>>> All the best,
>>>>>>>>>> Joan
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
>>>>>>>>>>> To: dev@couchdb.apache.org <javascript:;>
>>>>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>>>>>>>
>>>>>>>>>>> Hi Robert -
>>>>>>>>>>>
>>>>>>>>>>> As a builder of UI, API and library code who has also done developer
>>>>>>>>>>> training on a variety of technologies, one simple fix might be go
>>>>>>>>>>> ahead and
>>>>>>>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>>>>>>>> is
>>>>>>>>>>> such a piece of documentation) that states: "Note that the examples
>>>>>>>>>>> in this
>>>>>>>>>>> document do not require you to build an index, but for performance
>>>>>>>>>>> reasons
>>>>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
>>>>> information
>>>>>>>>>>> about
>>>>>>>>>>> how to do that" (or some such verbiage).
>>>>>>>>>>>
>>>>>>>>>>> My 2 cents.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> - Bill
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
>>>>> <javascript:;>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi list,
>>>>>>>>>>>>
>>>>>>>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>>>>>>>> the
>>>>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>>>>>>>> UIs)
>>>>>>>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>>>>>>>> the
>>>>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>>>>>>>> errors which are hard to debug and support.
>>>>>>>>>>>>
>>>>>>>>>>>> I added some thoughts to the other points you made:
>>>>>>>>>>>>
>>>>>>>>>>>>> a) know that the slow queries logs exist,
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>>>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>>>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>>>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>>>>>>>> The
>>>>>>>>>>>> problem does occur with all kinds of log message we produce in
>>>>>>>>>>>> CouchDB
>>>>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 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".
>>>>>>>>>>>>
>>>>>>>>>>>> I really like the migration path you mentioned here with the API to
>>>>>>>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>>>>>>>> absolute newcomers, people that you want to play around before they
>>>>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>>>>>>>> index
>>>>>>>>>>>> topic from the beginning to the querying.
>>>>>>>>>>>>
>>>>>>>>>>>> When I throw too much things to learn on people (which may not
>>>>>>>>>>>> have
>>>>>>>>>>>> used a database before), most people get discouraged and does not
>>>>>>>>>>>> take
>>>>>>>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>>>>>>>> "I
>>>>>>>>>>>> have not enough time", "product XY is easier to use".
>>>>>>>>>>>>
>>>>>>>>>>>> I would argue that newcomers to a database will launch a high
>>>>>>>>>>>> traffic,
>>>>>>>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>>>>>>>> the
>>>>>>>>>>>> day where they learn how to query the data and put data into the
>>>>>>>>>>>> database. Even for scenarios where people have a running high
>>>>>>>>>>>> traffic
>>>>>>>>>>>> system, and have used other databases at a medium to large scale I
>>>>>>>>>>>> would expect given they migrate to Couch, that they run both
>>>>>>>>>>>> systems
>>>>>>>>>>>> in parallel for the first time in order to fix the issues that
>>>>>>>>>>>> occur
>>>>>>>>>>>> during a migration.
>>>>>>>>>>>>
>>>>>>>>>>>> I think we we share the same goal (getting beginners started
>>>>>>>>>>>> quickly)
>>>>>>>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>>>>>>>> required knowledge to run a production system right from the very
>>>>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>>>>>>>> cognitive
>>>>>>>>>>>> load required to get the very first basic results, e.g. in a
>>>>>>>>>>>> university class setting - or junior developers on their "casual
>>>>>>>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>>>>>>>> traffic
>>>>>>>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>>>>>>>> they
>>>>>>>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>>>>>>>> with
>>>>>>>>>>>> more than a few thousand documents.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>>>>>>>> different. I also think this discussion still makes progress, but I
>>>>>>>>>>>> am
>>>>>>>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>>>>>>>> and
>>>>>>>>>>>> I would like to invite the other folks from the mailing list that
>>>>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>>>>>>>> again
>>>>>>>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>>>>>>>> answer :)
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>> Robert :)
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> - 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
Re: [POC] Mango Catch All Selector
Posted by Jan Lehnardt <ja...@apache.org>.
This is awesome: +1
> On 18 Jan 2016, at 00:16, Robert Kowalski <ro...@kowalski.gd> wrote:
>
> Heya,
>
> thanks again for all the feedback! I built a prototype and added a demo video!
>
>> I think the current design constraint around text is a good one, and I'm
>> unconvinced including English text is a good direction.
>>
>> If you want to take this direction, including a URL to our documentation
>> instead (which *is* internationalized) is probably a better way to go,
>> something like:
>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
>
> I really like this idea! I thought long about it and I think it grows
> the scope of the current task. Right now all strings CouchDB returns
> to the user are written in English. The current message that no index
> exists is also in english. Sadly our documentation is not
> internationalised yet - afaik no language has a complete translation
> and the translations are not available as a website or in any other
> public form. I stopped translating to German myself as the promised
> integration into the doc build was never finished in ~1.5 years. For
> the specific task right now I would like to keep the scope as small as
> possible. This does not mean that I would stand in the way if folks
> want to add i18n to the project and its sub-projects and have the
> tooling and time to maintain it.
>
>
> Because a prototype speaks more than 1000 posts I hacked a prototype
> which includes the warning that was proposed by Garren. You can check
> it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
> the video: https://cloudup.com/cEnbWqbX5Y7
>
> What do you think?
>
> On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> On 13 Jan 2016, at 23:41, Joan Touzet <wo...@apache.org> wrote:
>>>
>>> Warning: If we start using English text in a response such as this, we'll
>>> need to start externalising strings and internationalising them. We've never
>>> had to do this before because our API is, in general, terse and relies on
>>> HTTP status codes to indicate when something has gone wrong.
>>>
>>> I think the current design constraint around text is a good one, and I'm
>>> unconvinced including English text is a good direction.
>>>
>>> If you want to take this direction, including a URL to our documentation
>>> instead (which *is* internationalized) is probably a better way to go,
>>> something like:
>>>
>>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
>>
>> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
>> something like this!
>>
>> Great discussion everyone. I like how we are all making this idea better together :)
>>
>> Best
>> Jan
>> --
>>
>>
>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Robert Kowalski" <ro...@kowalski.gd>
>>> To: dev@couchdb.apache.org
>>> Sent: Wednesday, January 13, 2016 2:47:27 PM
>>> Subject: Re: [POC] Mango Catch All Selector
>>>
>>> Hi Garren,
>>>
>>> what would selector: null do? Return all docs?
>>>
>>> Where in the answer from CouchDB would be the warning? Next to the
>>> resultset, like
>>>
>>> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
>>> better performance"}] ?
>>>
>>> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
>>>
>>>> Hi Robert,
>>>>
>>>> I think you miss understood me, I don’t want it to be a different endpoint.
>>>> I just don’t want a user to have to do queries like this find({slow:
>>>> true}). I want them to be able to do a query e.g. find({}) or
>>>> find({selector: null}) and then get back the results along with a warning
>>>> message telling them that this query would be slow in production.
>>>> The lower the barrier for entry here the better. I know we want to protect
>>>> our users for when they go to production, but forcing them to add a slow:
>>>> true flag won’t help. It will still require them to read the docs a lot
>>>> more than most people are willing to on a first attempt of something new.
>>>>
>>>> Cheers
>>>> Garren
>>>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
>>>> <javascript:;>> wrote:
>>>>>
>>>>> thank you all for your feedback!
>>>>>
>>>>> i like the idea of the error message with a new url.
>>>>>
>>>>> i agree with garren that it should be a separate endpoint. it takes
>>>>> some complexity off when explaining each endpoint.
>>>>>
>>>>> maybe: `/_find_slow`?
>>>>>
>>>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
>>>> <javascript:;>> wrote:
>>>>>>
>>>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
>>>> <javascript:;>> wrote:
>>>>>>>
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> Building upon what others have stated above, what do you think about
>>>>>>> the following:
>>>>>>>
>>>>>>> 1) Let the user query without creating an index
>>>>>>> 2) Return an error message with a new url that has
>>>>>>> "slow/no_index/developer":true appended at the end. The message clearly
>>>>>>> explains that this query will be slow, and that creating an index will
>>>> be
>>>>>>> more efficient. However, he or she can continue. The error message will
>>>>>>> then have a link to point to our documentation.
>>>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
>>>>>>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>>>>>>> then the same message pops up to notify the user.
>>>>>>
>>>>>>
>>>>>> I like this!
>>>>>>
>>>>>>
>>>>>> Jan
>>>>>> --
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Tony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
>>>> wickedgrey@gmail.com <javascript:;>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Just wanted to chime in here as a user - I've run into similar
>>>>>>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>>>>>>> where stuff I was working on went smoothly in dev, but stopped once
>>>>>>>> real load was pushed through it (thankfully for me, that was in
>>>>>>>> testing, rather than released to customers).
>>>>>>>>
>>>>>>>> It's a frustrating experience, and I don't think that a reputation for
>>>>>>>> "works until you cross a threshold, and then it doesn't, but only in
>>>>>>>> production" is a good thing to move towards.
>>>>>>>>
>>>>>>>> Perhaps something like adding a key to the returned data along the
>>>>>>>> lines of "_slow_warning": "This query is going to be slow on large
>>>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
>>>> query
>>>>>>>> param (note that I'm calling it "slow_warning" in both places only to
>>>>>>>> increase discoverability; without the url param, the no-index query
>>>>>>>> wouldn't work at all). Bikeshed the name as needed.
>>>>>>>>
>>>>>>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>>>>>>> actually - I would find it very useful when trying to determine what's
>>>>>>>> going wrong to have a URL right there in the logs that I can get more
>>>>>>>> information from.
>>>>>>>>
>>>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
>>>> <javascript:;>> wrote:
>>>>>>>>> Hi Robert,
>>>>>>>>>
>>>>>>>>> I've been thinking about this one for the week or so, and I have a
>>>>>>>>> simple suggestion:
>>>>>>>>>
>>>>>>>>> Add the query parameter slow=true to enable this behaviour.
>>>>>>>>>
>>>>>>>>> This meets all the original requirements:
>>>>>>>>>
>>>>>>>>> 1. It is not default behaviour
>>>>>>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>>>>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>>>>>>> a break, and be forced to learn about indexes
>>>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>>>>>>
>>>>>>>>> All the best,
>>>>>>>>> Joan
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
>>>>>>>>>> To: dev@couchdb.apache.org <javascript:;>
>>>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>>>>>>
>>>>>>>>>> Hi Robert -
>>>>>>>>>>
>>>>>>>>>> As a builder of UI, API and library code who has also done developer
>>>>>>>>>> training on a variety of technologies, one simple fix might be go
>>>>>>>>>> ahead and
>>>>>>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>>>>>>> is
>>>>>>>>>> such a piece of documentation) that states: "Note that the examples
>>>>>>>>>> in this
>>>>>>>>>> document do not require you to build an index, but for performance
>>>>>>>>>> reasons
>>>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
>>>> information
>>>>>>>>>> about
>>>>>>>>>> how to do that" (or some such verbiage).
>>>>>>>>>>
>>>>>>>>>> My 2 cents.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> - Bill
>>>>>>>>>>
>>>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
>>>> <javascript:;>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi list,
>>>>>>>>>>>
>>>>>>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>>>>>>> the
>>>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>>>>>>> UIs)
>>>>>>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>>>>>>> the
>>>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>>>>>>
>>>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>>>>>>> errors which are hard to debug and support.
>>>>>>>>>>>
>>>>>>>>>>> I added some thoughts to the other points you made:
>>>>>>>>>>>
>>>>>>>>>>>> a) know that the slow queries logs exist,
>>>>>>>>>>>
>>>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>>>>>>> The
>>>>>>>>>>> problem does occur with all kinds of log message we produce in
>>>>>>>>>>> CouchDB
>>>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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".
>>>>>>>>>>>
>>>>>>>>>>> I really like the migration path you mentioned here with the API to
>>>>>>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>>>>>>> absolute newcomers, people that you want to play around before they
>>>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>>>>>>> index
>>>>>>>>>>> topic from the beginning to the querying.
>>>>>>>>>>>
>>>>>>>>>>> When I throw too much things to learn on people (which may not
>>>>>>>>>>> have
>>>>>>>>>>> used a database before), most people get discouraged and does not
>>>>>>>>>>> take
>>>>>>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>>>>>>> "I
>>>>>>>>>>> have not enough time", "product XY is easier to use".
>>>>>>>>>>>
>>>>>>>>>>> I would argue that newcomers to a database will launch a high
>>>>>>>>>>> traffic,
>>>>>>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>>>>>>> the
>>>>>>>>>>> day where they learn how to query the data and put data into the
>>>>>>>>>>> database. Even for scenarios where people have a running high
>>>>>>>>>>> traffic
>>>>>>>>>>> system, and have used other databases at a medium to large scale I
>>>>>>>>>>> would expect given they migrate to Couch, that they run both
>>>>>>>>>>> systems
>>>>>>>>>>> in parallel for the first time in order to fix the issues that
>>>>>>>>>>> occur
>>>>>>>>>>> during a migration.
>>>>>>>>>>>
>>>>>>>>>>> I think we we share the same goal (getting beginners started
>>>>>>>>>>> quickly)
>>>>>>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>>>>>>> required knowledge to run a production system right from the very
>>>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>>>>>>> cognitive
>>>>>>>>>>> load required to get the very first basic results, e.g. in a
>>>>>>>>>>> university class setting - or junior developers on their "casual
>>>>>>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>>>>>>> traffic
>>>>>>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>>>>>>> they
>>>>>>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>>>>>>> with
>>>>>>>>>>> more than a few thousand documents.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>>>>>>> different. I also think this discussion still makes progress, but I
>>>>>>>>>>> am
>>>>>>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>>>>>>> and
>>>>>>>>>>> I would like to invite the other folks from the mailing list that
>>>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>>>>>>> again
>>>>>>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>>>>>>> answer :)
>>>>>>>>>>>
>>>>>>>>>>> Best,
>>>>>>>>>>> Robert :)
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> - 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>
Re: [POC] Mango Catch All Selector
Posted by Robert Kowalski <ro...@kowalski.gd>.
Heya,
thanks again for all the feedback! I built a prototype and added a demo video!
> I think the current design constraint around text is a good one, and I'm
> unconvinced including English text is a good direction.
>
> If you want to take this direction, including a URL to our documentation
> instead (which *is* internationalized) is probably a better way to go,
> something like:
> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
I really like this idea! I thought long about it and I think it grows
the scope of the current task. Right now all strings CouchDB returns
to the user are written in English. The current message that no index
exists is also in english. Sadly our documentation is not
internationalised yet - afaik no language has a complete translation
and the translations are not available as a website or in any other
public form. I stopped translating to German myself as the promised
integration into the doc build was never finished in ~1.5 years. For
the specific task right now I would like to keep the scope as small as
possible. This does not mean that I would stand in the way if folks
want to add i18n to the project and its sub-projects and have the
tooling and time to maintain it.
Because a prototype speaks more than 1000 posts I hacked a prototype
which includes the warning that was proposed by Garren. You can check
it out at https://github.com/apache/couchdb-mango/pull/27 - or watch
the video: https://cloudup.com/cEnbWqbX5Y7
What do you think?
On Wed, Jan 13, 2016 at 11:58 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> On 13 Jan 2016, at 23:41, Joan Touzet <wo...@apache.org> wrote:
>>
>> Warning: If we start using English text in a response such as this, we'll
>> need to start externalising strings and internationalising them. We've never
>> had to do this before because our API is, in general, terse and relies on
>> HTTP status codes to indicate when something has gone wrong.
>>
>> I think the current design constraint around text is a good one, and I'm
>> unconvinced including English text is a good direction.
>>
>> If you want to take this direction, including a URL to our documentation
>> instead (which *is* internationalized) is probably a better way to go,
>> something like:
>>
>> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
>
> bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
> something like this!
>
> Great discussion everyone. I like how we are all making this idea better together :)
>
> Best
> Jan
> --
>
>
>
>>
>>
>>
>> ----- Original Message -----
>> From: "Robert Kowalski" <ro...@kowalski.gd>
>> To: dev@couchdb.apache.org
>> Sent: Wednesday, January 13, 2016 2:47:27 PM
>> Subject: Re: [POC] Mango Catch All Selector
>>
>> Hi Garren,
>>
>> what would selector: null do? Return all docs?
>>
>> Where in the answer from CouchDB would be the warning? Next to the
>> resultset, like
>>
>> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
>> better performance"}] ?
>>
>> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
>>
>>> Hi Robert,
>>>
>>> I think you miss understood me, I don’t want it to be a different endpoint.
>>> I just don’t want a user to have to do queries like this find({slow:
>>> true}). I want them to be able to do a query e.g. find({}) or
>>> find({selector: null}) and then get back the results along with a warning
>>> message telling them that this query would be slow in production.
>>> The lower the barrier for entry here the better. I know we want to protect
>>> our users for when they go to production, but forcing them to add a slow:
>>> true flag won’t help. It will still require them to read the docs a lot
>>> more than most people are willing to on a first attempt of something new.
>>>
>>> Cheers
>>> Garren
>>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
>>> <javascript:;>> wrote:
>>>>
>>>> thank you all for your feedback!
>>>>
>>>> i like the idea of the error message with a new url.
>>>>
>>>> i agree with garren that it should be a separate endpoint. it takes
>>>> some complexity off when explaining each endpoint.
>>>>
>>>> maybe: `/_find_slow`?
>>>>
>>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
>>> <javascript:;>> wrote:
>>>>>
>>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
>>> <javascript:;>> wrote:
>>>>>>
>>>>>> Hi Robert,
>>>>>>
>>>>>> Building upon what others have stated above, what do you think about
>>>>>> the following:
>>>>>>
>>>>>> 1) Let the user query without creating an index
>>>>>> 2) Return an error message with a new url that has
>>>>>> "slow/no_index/developer":true appended at the end. The message clearly
>>>>>> explains that this query will be slow, and that creating an index will
>>> be
>>>>>> more efficient. However, he or she can continue. The error message will
>>>>>> then have a link to point to our documentation.
>>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
>>>>>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>>>>>> then the same message pops up to notify the user.
>>>>>
>>>>>
>>>>> I like this!
>>>>>
>>>>>
>>>>> Jan
>>>>> --
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
>>> wickedgrey@gmail.com <javascript:;>>
>>>>>> wrote:
>>>>>>
>>>>>>> Just wanted to chime in here as a user - I've run into similar
>>>>>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>>>>>> where stuff I was working on went smoothly in dev, but stopped once
>>>>>>> real load was pushed through it (thankfully for me, that was in
>>>>>>> testing, rather than released to customers).
>>>>>>>
>>>>>>> It's a frustrating experience, and I don't think that a reputation for
>>>>>>> "works until you cross a threshold, and then it doesn't, but only in
>>>>>>> production" is a good thing to move towards.
>>>>>>>
>>>>>>> Perhaps something like adding a key to the returned data along the
>>>>>>> lines of "_slow_warning": "This query is going to be slow on large
>>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
>>> query
>>>>>>> param (note that I'm calling it "slow_warning" in both places only to
>>>>>>> increase discoverability; without the url param, the no-index query
>>>>>>> wouldn't work at all). Bikeshed the name as needed.
>>>>>>>
>>>>>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>>>>>> actually - I would find it very useful when trying to determine what's
>>>>>>> going wrong to have a URL right there in the logs that I can get more
>>>>>>> information from.
>>>>>>>
>>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
>>> <javascript:;>> wrote:
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> I've been thinking about this one for the week or so, and I have a
>>>>>>>> simple suggestion:
>>>>>>>>
>>>>>>>> Add the query parameter slow=true to enable this behaviour.
>>>>>>>>
>>>>>>>> This meets all the original requirements:
>>>>>>>>
>>>>>>>> 1. It is not default behaviour
>>>>>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>>>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>>>>>> a break, and be forced to learn about indexes
>>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>>>>>
>>>>>>>> All the best,
>>>>>>>> Joan
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
>>>>>>>>> To: dev@couchdb.apache.org <javascript:;>
>>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>>>>>
>>>>>>>>> Hi Robert -
>>>>>>>>>
>>>>>>>>> As a builder of UI, API and library code who has also done developer
>>>>>>>>> training on a variety of technologies, one simple fix might be go
>>>>>>>>> ahead and
>>>>>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>>>>>> is
>>>>>>>>> such a piece of documentation) that states: "Note that the examples
>>>>>>>>> in this
>>>>>>>>> document do not require you to build an index, but for performance
>>>>>>>>> reasons
>>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
>>> information
>>>>>>>>> about
>>>>>>>>> how to do that" (or some such verbiage).
>>>>>>>>>
>>>>>>>>> My 2 cents.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> - Bill
>>>>>>>>>
>>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
>>> <javascript:;>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi list,
>>>>>>>>>>
>>>>>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>>>>>> the
>>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>>>>>> UIs)
>>>>>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>>>>>> the
>>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>>>>>
>>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>>>>>> errors which are hard to debug and support.
>>>>>>>>>>
>>>>>>>>>> I added some thoughts to the other points you made:
>>>>>>>>>>
>>>>>>>>>>> a) know that the slow queries logs exist,
>>>>>>>>>>
>>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>>>>>> The
>>>>>>>>>> problem does occur with all kinds of log message we produce in
>>>>>>>>>> CouchDB
>>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 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".
>>>>>>>>>>
>>>>>>>>>> I really like the migration path you mentioned here with the API to
>>>>>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>>>>>> absolute newcomers, people that you want to play around before they
>>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>>>>>> index
>>>>>>>>>> topic from the beginning to the querying.
>>>>>>>>>>
>>>>>>>>>> When I throw too much things to learn on people (which may not
>>>>>>>>>> have
>>>>>>>>>> used a database before), most people get discouraged and does not
>>>>>>>>>> take
>>>>>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>>>>>> "I
>>>>>>>>>> have not enough time", "product XY is easier to use".
>>>>>>>>>>
>>>>>>>>>> I would argue that newcomers to a database will launch a high
>>>>>>>>>> traffic,
>>>>>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>>>>>> the
>>>>>>>>>> day where they learn how to query the data and put data into the
>>>>>>>>>> database. Even for scenarios where people have a running high
>>>>>>>>>> traffic
>>>>>>>>>> system, and have used other databases at a medium to large scale I
>>>>>>>>>> would expect given they migrate to Couch, that they run both
>>>>>>>>>> systems
>>>>>>>>>> in parallel for the first time in order to fix the issues that
>>>>>>>>>> occur
>>>>>>>>>> during a migration.
>>>>>>>>>>
>>>>>>>>>> I think we we share the same goal (getting beginners started
>>>>>>>>>> quickly)
>>>>>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>>>>>> required knowledge to run a production system right from the very
>>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>>>>>> cognitive
>>>>>>>>>> load required to get the very first basic results, e.g. in a
>>>>>>>>>> university class setting - or junior developers on their "casual
>>>>>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>>>>>> traffic
>>>>>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>>>>>> they
>>>>>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>>>>>> with
>>>>>>>>>> more than a few thousand documents.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>>>>>> different. I also think this discussion still makes progress, but I
>>>>>>>>>> am
>>>>>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>>>>>> and
>>>>>>>>>> I would like to invite the other folks from the mailing list that
>>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>>>>>> again
>>>>>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>>>>>> answer :)
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>> Robert :)
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>> - 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>
Re: [POC] Mango Catch All Selector
Posted by Jan Lehnardt <ja...@apache.org>.
> On 13 Jan 2016, at 23:41, Joan Touzet <wo...@apache.org> wrote:
>
> Warning: If we start using English text in a response such as this, we'll
> need to start externalising strings and internationalising them. We've never
> had to do this before because our API is, in general, terse and relies on
> HTTP status codes to indicate when something has gone wrong.
>
> I think the current design constraint around text is a good one, and I'm
> unconvinced including English text is a good direction.
>
> If you want to take this direction, including a URL to our documentation
> instead (which *is* internationalized) is probably a better way to go,
> something like:
>
> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
bikeshed: maybe slow_warning (like we use not_found on 404s), but yeah,
something like this!
Great discussion everyone. I like how we are all making this idea better together :)
Best
Jan
--
>
>
>
> ----- Original Message -----
> From: "Robert Kowalski" <ro...@kowalski.gd>
> To: dev@couchdb.apache.org
> Sent: Wednesday, January 13, 2016 2:47:27 PM
> Subject: Re: [POC] Mango Catch All Selector
>
> Hi Garren,
>
> what would selector: null do? Return all docs?
>
> Where in the answer from CouchDB would be the warning? Next to the
> resultset, like
>
> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
> better performance"}] ?
>
> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
>
>> Hi Robert,
>>
>> I think you miss understood me, I don’t want it to be a different endpoint.
>> I just don’t want a user to have to do queries like this find({slow:
>> true}). I want them to be able to do a query e.g. find({}) or
>> find({selector: null}) and then get back the results along with a warning
>> message telling them that this query would be slow in production.
>> The lower the barrier for entry here the better. I know we want to protect
>> our users for when they go to production, but forcing them to add a slow:
>> true flag won’t help. It will still require them to read the docs a lot
>> more than most people are willing to on a first attempt of something new.
>>
>> Cheers
>> Garren
>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
>> <javascript:;>> wrote:
>>>
>>> thank you all for your feedback!
>>>
>>> i like the idea of the error message with a new url.
>>>
>>> i agree with garren that it should be a separate endpoint. it takes
>>> some complexity off when explaining each endpoint.
>>>
>>> maybe: `/_find_slow`?
>>>
>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
>> <javascript:;>> wrote:
>>>>
>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
>> <javascript:;>> wrote:
>>>>>
>>>>> Hi Robert,
>>>>>
>>>>> Building upon what others have stated above, what do you think about
>>>>> the following:
>>>>>
>>>>> 1) Let the user query without creating an index
>>>>> 2) Return an error message with a new url that has
>>>>> "slow/no_index/developer":true appended at the end. The message clearly
>>>>> explains that this query will be slow, and that creating an index will
>> be
>>>>> more efficient. However, he or she can continue. The error message will
>>>>> then have a link to point to our documentation.
>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
>>>>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>>>>> then the same message pops up to notify the user.
>>>>
>>>>
>>>> I like this!
>>>>
>>>>
>>>> Jan
>>>> --
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Tony
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
>> wickedgrey@gmail.com <javascript:;>>
>>>>> wrote:
>>>>>
>>>>>> Just wanted to chime in here as a user - I've run into similar
>>>>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>>>>> where stuff I was working on went smoothly in dev, but stopped once
>>>>>> real load was pushed through it (thankfully for me, that was in
>>>>>> testing, rather than released to customers).
>>>>>>
>>>>>> It's a frustrating experience, and I don't think that a reputation for
>>>>>> "works until you cross a threshold, and then it doesn't, but only in
>>>>>> production" is a good thing to move towards.
>>>>>>
>>>>>> Perhaps something like adding a key to the returned data along the
>>>>>> lines of "_slow_warning": "This query is going to be slow on large
>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
>> query
>>>>>> param (note that I'm calling it "slow_warning" in both places only to
>>>>>> increase discoverability; without the url param, the no-index query
>>>>>> wouldn't work at all). Bikeshed the name as needed.
>>>>>>
>>>>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>>>>> actually - I would find it very useful when trying to determine what's
>>>>>> going wrong to have a URL right there in the logs that I can get more
>>>>>> information from.
>>>>>>
>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
>> <javascript:;>> wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> I've been thinking about this one for the week or so, and I have a
>>>>>>> simple suggestion:
>>>>>>>
>>>>>>> Add the query parameter slow=true to enable this behaviour.
>>>>>>>
>>>>>>> This meets all the original requirements:
>>>>>>>
>>>>>>> 1. It is not default behaviour
>>>>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>>>>> a break, and be forced to learn about indexes
>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>>>>
>>>>>>> All the best,
>>>>>>> Joan
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
>>>>>>>> To: dev@couchdb.apache.org <javascript:;>
>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>>>>
>>>>>>>> Hi Robert -
>>>>>>>>
>>>>>>>> As a builder of UI, API and library code who has also done developer
>>>>>>>> training on a variety of technologies, one simple fix might be go
>>>>>>>> ahead and
>>>>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>>>>> is
>>>>>>>> such a piece of documentation) that states: "Note that the examples
>>>>>>>> in this
>>>>>>>> document do not require you to build an index, but for performance
>>>>>>>> reasons
>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
>> information
>>>>>>>> about
>>>>>>>> how to do that" (or some such verbiage).
>>>>>>>>
>>>>>>>> My 2 cents.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> - Bill
>>>>>>>>
>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
>> <javascript:;>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi list,
>>>>>>>>>
>>>>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>>>>> the
>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>>>>> UIs)
>>>>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>>>>> the
>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>>>>
>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>>>>> errors which are hard to debug and support.
>>>>>>>>>
>>>>>>>>> I added some thoughts to the other points you made:
>>>>>>>>>
>>>>>>>>>> a) know that the slow queries logs exist,
>>>>>>>>>
>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>>>>> The
>>>>>>>>> problem does occur with all kinds of log message we produce in
>>>>>>>>> CouchDB
>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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".
>>>>>>>>>
>>>>>>>>> I really like the migration path you mentioned here with the API to
>>>>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>>>>> absolute newcomers, people that you want to play around before they
>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>>>>> index
>>>>>>>>> topic from the beginning to the querying.
>>>>>>>>>
>>>>>>>>> When I throw too much things to learn on people (which may not
>>>>>>>>> have
>>>>>>>>> used a database before), most people get discouraged and does not
>>>>>>>>> take
>>>>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>>>>> "I
>>>>>>>>> have not enough time", "product XY is easier to use".
>>>>>>>>>
>>>>>>>>> I would argue that newcomers to a database will launch a high
>>>>>>>>> traffic,
>>>>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>>>>> the
>>>>>>>>> day where they learn how to query the data and put data into the
>>>>>>>>> database. Even for scenarios where people have a running high
>>>>>>>>> traffic
>>>>>>>>> system, and have used other databases at a medium to large scale I
>>>>>>>>> would expect given they migrate to Couch, that they run both
>>>>>>>>> systems
>>>>>>>>> in parallel for the first time in order to fix the issues that
>>>>>>>>> occur
>>>>>>>>> during a migration.
>>>>>>>>>
>>>>>>>>> I think we we share the same goal (getting beginners started
>>>>>>>>> quickly)
>>>>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>>>>> required knowledge to run a production system right from the very
>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>>>>> cognitive
>>>>>>>>> load required to get the very first basic results, e.g. in a
>>>>>>>>> university class setting - or junior developers on their "casual
>>>>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>>>>> traffic
>>>>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>>>>> they
>>>>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>>>>> with
>>>>>>>>> more than a few thousand documents.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>>>>> different. I also think this discussion still makes progress, but I
>>>>>>>>> am
>>>>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>>>>> and
>>>>>>>>> I would like to invite the other folks from the mailing list that
>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>>>>> again
>>>>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>>>>> answer :)
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Robert :)
>>>>>>>>>
>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
>>>>>>>>> wrote:
>>>>>>>>>>>> - 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.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>>
Re: [POC] Mango Catch All Selector
Posted by Jan Lehnardt <ja...@apache.org>.
> On 13 Jan 2016, at 23:41, Joan Touzet <wo...@apache.org> wrote:
>
> Warning: If we start using English text in a response such as this, we'll
> need to start externalising strings and internationalising them. We've never
> had to do this before because our API is, in general, terse and relies on
> HTTP status codes to indicate when something has gone wrong.
>
> I think the current design constraint around text is a good one, and I'm
> unconvinced including English text is a good direction.
>
> If you want to take this direction, including a URL to our documentation
> instead (which *is* internationalized) is probably a better way to go,
> something like:
>
> .... {"_warning": "http://docs.couchdb.org/en/2.0.0/.....”}]
I like this improvement :)
Best
Jan
--
>
>
>
> ----- Original Message -----
> From: "Robert Kowalski" <ro...@kowalski.gd>
> To: dev@couchdb.apache.org
> Sent: Wednesday, January 13, 2016 2:47:27 PM
> Subject: Re: [POC] Mango Catch All Selector
>
> Hi Garren,
>
> what would selector: null do? Return all docs?
>
> Where in the answer from CouchDB would be the warning? Next to the
> resultset, like
>
> [{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
> better performance"}] ?
>
> Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
>
>> Hi Robert,
>>
>> I think you miss understood me, I don’t want it to be a different endpoint.
>> I just don’t want a user to have to do queries like this find({slow:
>> true}). I want them to be able to do a query e.g. find({}) or
>> find({selector: null}) and then get back the results along with a warning
>> message telling them that this query would be slow in production.
>> The lower the barrier for entry here the better. I know we want to protect
>> our users for when they go to production, but forcing them to add a slow:
>> true flag won’t help. It will still require them to read the docs a lot
>> more than most people are willing to on a first attempt of something new.
>>
>> Cheers
>> Garren
>>> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
>> <javascript:;>> wrote:
>>>
>>> thank you all for your feedback!
>>>
>>> i like the idea of the error message with a new url.
>>>
>>> i agree with garren that it should be a separate endpoint. it takes
>>> some complexity off when explaining each endpoint.
>>>
>>> maybe: `/_find_slow`?
>>>
>>> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
>> <javascript:;>> wrote:
>>>>
>>>>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
>> <javascript:;>> wrote:
>>>>>
>>>>> Hi Robert,
>>>>>
>>>>> Building upon what others have stated above, what do you think about
>>>>> the following:
>>>>>
>>>>> 1) Let the user query without creating an index
>>>>> 2) Return an error message with a new url that has
>>>>> "slow/no_index/developer":true appended at the end. The message clearly
>>>>> explains that this query will be slow, and that creating an index will
>> be
>>>>> more efficient. However, he or she can continue. The error message will
>>>>> then have a link to point to our documentation.
>>>>> 3) In Fauxton, there is a checkbox or button that also appends the
>>>>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>>>>> then the same message pops up to notify the user.
>>>>
>>>>
>>>> I like this!
>>>>
>>>>
>>>> Jan
>>>> --
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Tony
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
>> wickedgrey@gmail.com <javascript:;>>
>>>>> wrote:
>>>>>
>>>>>> Just wanted to chime in here as a user - I've run into similar
>>>>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>>>>> where stuff I was working on went smoothly in dev, but stopped once
>>>>>> real load was pushed through it (thankfully for me, that was in
>>>>>> testing, rather than released to customers).
>>>>>>
>>>>>> It's a frustrating experience, and I don't think that a reputation for
>>>>>> "works until you cross a threshold, and then it doesn't, but only in
>>>>>> production" is a good thing to move towards.
>>>>>>
>>>>>> Perhaps something like adding a key to the returned data along the
>>>>>> lines of "_slow_warning": "This query is going to be slow on large
>>>>>> data sets. See http://..." in addition to the ?slow_warning=true
>> query
>>>>>> param (note that I'm calling it "slow_warning" in both places only to
>>>>>> increase discoverability; without the url param, the no-index query
>>>>>> wouldn't work at all). Bikeshed the name as needed.
>>>>>>
>>>>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>>>>> actually - I would find it very useful when trying to determine what's
>>>>>> going wrong to have a URL right there in the logs that I can get more
>>>>>> information from.
>>>>>>
>>>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
>> <javascript:;>> wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> I've been thinking about this one for the week or so, and I have a
>>>>>>> simple suggestion:
>>>>>>>
>>>>>>> Add the query parameter slow=true to enable this behaviour.
>>>>>>>
>>>>>>> This meets all the original requirements:
>>>>>>>
>>>>>>> 1. It is not default behaviour
>>>>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>>>>> a break, and be forced to learn about indexes
>>>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>>>>
>>>>>>> All the best,
>>>>>>> Joan
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
>>>>>>>> To: dev@couchdb.apache.org <javascript:;>
>>>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>>>>
>>>>>>>> Hi Robert -
>>>>>>>>
>>>>>>>> As a builder of UI, API and library code who has also done developer
>>>>>>>> training on a variety of technologies, one simple fix might be go
>>>>>>>> ahead and
>>>>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>>>>> is
>>>>>>>> such a piece of documentation) that states: "Note that the examples
>>>>>>>> in this
>>>>>>>> document do not require you to build an index, but for performance
>>>>>>>> reasons
>>>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
>> information
>>>>>>>> about
>>>>>>>> how to do that" (or some such verbiage).
>>>>>>>>
>>>>>>>> My 2 cents.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> - Bill
>>>>>>>>
>>>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
>> <javascript:;>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi list,
>>>>>>>>>
>>>>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>>>>> the
>>>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>>>>> UIs)
>>>>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>>>>> the
>>>>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>>>>
>>>>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>>>>> errors which are hard to debug and support.
>>>>>>>>>
>>>>>>>>> I added some thoughts to the other points you made:
>>>>>>>>>
>>>>>>>>>> a) know that the slow queries logs exist,
>>>>>>>>>
>>>>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>>>>> The
>>>>>>>>> problem does occur with all kinds of log message we produce in
>>>>>>>>> CouchDB
>>>>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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".
>>>>>>>>>
>>>>>>>>> I really like the migration path you mentioned here with the API to
>>>>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>>>>> absolute newcomers, people that you want to play around before they
>>>>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>>>>> index
>>>>>>>>> topic from the beginning to the querying.
>>>>>>>>>
>>>>>>>>> When I throw too much things to learn on people (which may not
>>>>>>>>> have
>>>>>>>>> used a database before), most people get discouraged and does not
>>>>>>>>> take
>>>>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>>>>> "I
>>>>>>>>> have not enough time", "product XY is easier to use".
>>>>>>>>>
>>>>>>>>> I would argue that newcomers to a database will launch a high
>>>>>>>>> traffic,
>>>>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>>>>> the
>>>>>>>>> day where they learn how to query the data and put data into the
>>>>>>>>> database. Even for scenarios where people have a running high
>>>>>>>>> traffic
>>>>>>>>> system, and have used other databases at a medium to large scale I
>>>>>>>>> would expect given they migrate to Couch, that they run both
>>>>>>>>> systems
>>>>>>>>> in parallel for the first time in order to fix the issues that
>>>>>>>>> occur
>>>>>>>>> during a migration.
>>>>>>>>>
>>>>>>>>> I think we we share the same goal (getting beginners started
>>>>>>>>> quickly)
>>>>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>>>>> required knowledge to run a production system right from the very
>>>>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>>>>> cognitive
>>>>>>>>> load required to get the very first basic results, e.g. in a
>>>>>>>>> university class setting - or junior developers on their "casual
>>>>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>>>>> traffic
>>>>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>>>>> they
>>>>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>>>>> with
>>>>>>>>> more than a few thousand documents.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>>>>> different. I also think this discussion still makes progress, but I
>>>>>>>>> am
>>>>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>>>>> and
>>>>>>>>> I would like to invite the other folks from the mailing list that
>>>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>>>>> again
>>>>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>>>>> answer :)
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Robert :)
>>>>>>>>>
>>>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
>>>>>>>>> wrote:
>>>>>>>>>>>> - 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.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>>
Re: [POC] Mango Catch All Selector
Posted by Joan Touzet <wo...@apache.org>.
Warning: If we start using English text in a response such as this, we'll
need to start externalising strings and internationalising them. We've never
had to do this before because our API is, in general, terse and relies on
HTTP status codes to indicate when something has gone wrong.
I think the current design constraint around text is a good one, and I'm
unconvinced including English text is a good direction.
If you want to take this direction, including a URL to our documentation
instead (which *is* internationalized) is probably a better way to go,
something like:
.... {"_warning": "http://docs.couchdb.org/en/2.0.0/....."}]
----- Original Message -----
From: "Robert Kowalski" <ro...@kowalski.gd>
To: dev@couchdb.apache.org
Sent: Wednesday, January 13, 2016 2:47:27 PM
Subject: Re: [POC] Mango Catch All Selector
Hi Garren,
what would selector: null do? Return all docs?
Where in the answer from CouchDB would be the warning? Next to the
resultset, like
[{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
better performance"}] ?
Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
> Hi Robert,
>
> I think you miss understood me, I don’t want it to be a different endpoint.
> I just don’t want a user to have to do queries like this find({slow:
> true}). I want them to be able to do a query e.g. find({}) or
> find({selector: null}) and then get back the results along with a warning
> message telling them that this query would be slow in production.
> The lower the barrier for entry here the better. I know we want to protect
> our users for when they go to production, but forcing them to add a slow:
> true flag won’t help. It will still require them to read the docs a lot
> more than most people are willing to on a first attempt of something new.
>
> Cheers
> Garren
> > On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
> <javascript:;>> wrote:
> >
> > thank you all for your feedback!
> >
> > i like the idea of the error message with a new url.
> >
> > i agree with garren that it should be a separate endpoint. it takes
> > some complexity off when explaining each endpoint.
> >
> > maybe: `/_find_slow`?
> >
> > On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
> <javascript:;>> wrote:
> >>
> >>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
> <javascript:;>> wrote:
> >>>
> >>> Hi Robert,
> >>>
> >>> Building upon what others have stated above, what do you think about
> >>> the following:
> >>>
> >>> 1) Let the user query without creating an index
> >>> 2) Return an error message with a new url that has
> >>> "slow/no_index/developer":true appended at the end. The message clearly
> >>> explains that this query will be slow, and that creating an index will
> be
> >>> more efficient. However, he or she can continue. The error message will
> >>> then have a link to point to our documentation.
> >>> 3) In Fauxton, there is a checkbox or button that also appends the
> >>> "slow/no_index/developer":true to the _find url. If the user clicks it,
> >>> then the same message pops up to notify the user.
> >>
> >>
> >> I like this!
> >>
> >>
> >> Jan
> >> --
> >>
> >>>
> >>>
> >>>
> >>> Tony
> >>>
> >>>
> >>>
> >>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
> wickedgrey@gmail.com <javascript:;>>
> >>> wrote:
> >>>
> >>>> Just wanted to chime in here as a user - I've run into similar
> >>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
> >>>> where stuff I was working on went smoothly in dev, but stopped once
> >>>> real load was pushed through it (thankfully for me, that was in
> >>>> testing, rather than released to customers).
> >>>>
> >>>> It's a frustrating experience, and I don't think that a reputation for
> >>>> "works until you cross a threshold, and then it doesn't, but only in
> >>>> production" is a good thing to move towards.
> >>>>
> >>>> Perhaps something like adding a key to the returned data along the
> >>>> lines of "_slow_warning": "This query is going to be slow on large
> >>>> data sets. See http://..." in addition to the ?slow_warning=true
> query
> >>>> param (note that I'm calling it "slow_warning" in both places only to
> >>>> increase discoverability; without the url param, the no-index query
> >>>> wouldn't work at all). Bikeshed the name as needed.
> >>>>
> >>>> I'd like to see a lot more URLs in CouchDB error messages in general,
> >>>> actually - I would find it very useful when trying to determine what's
> >>>> going wrong to have a URL right there in the logs that I can get more
> >>>> information from.
> >>>>
> >>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
> <javascript:;>> wrote:
> >>>>> Hi Robert,
> >>>>>
> >>>>> I've been thinking about this one for the week or so, and I have a
> >>>>> simple suggestion:
> >>>>>
> >>>>> Add the query parameter slow=true to enable this behaviour.
> >>>>>
> >>>>> This meets all the original requirements:
> >>>>>
> >>>>> 1. It is not default behaviour
> >>>>> 2. You can grep the log files for the word 'slow' and find evidence
> >>>>> 3. There is a shorthand, simple way to enable the behaviour
> >>>>> 4. Any self-respecting developer will try to remove slow=true, find
> >>>>> a break, and be forced to learn about indexes
> >>>>> 5. It's a bit cheeky, which I think is kind of fun :D
> >>>>>
> >>>>> All the best,
> >>>>> Joan
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
> >>>>>> To: dev@couchdb.apache.org <javascript:;>
> >>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
> >>>>>> Subject: Re: [POC] Mango Catch All Selector
> >>>>>>
> >>>>>> Hi Robert -
> >>>>>>
> >>>>>> As a builder of UI, API and library code who has also done developer
> >>>>>> training on a variety of technologies, one simple fix might be go
> >>>>>> ahead and
> >>>>>> not require indexes to be built, but then to put a big NOTE at the
> >>>>>> beginning of the "Mango Getting Started" guide (I would assume there
> >>>>>> is
> >>>>>> such a piece of documentation) that states: "Note that the examples
> >>>>>> in this
> >>>>>> document do not require you to build an index, but for performance
> >>>>>> reasons
> >>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
> information
> >>>>>> about
> >>>>>> how to do that" (or some such verbiage).
> >>>>>>
> >>>>>> My 2 cents.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> - Bill
> >>>>>>
> >>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
> <javascript:;>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi list,
> >>>>>>>
> >>>>>>> At the end of the mail I would like to invite the other folks from
> >>>>>>> the
> >>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
> >>>>>>> UIs)
> >>>>>>> to chime in again with their opinions. So all people one the ML,
> >>>>>>> the
> >>>>>>> mail is not just a response to Paul, feedback is welcome :)
> >>>>>>>
> >>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
> >>>>>>> errors which are hard to debug and support.
> >>>>>>>
> >>>>>>> I added some thoughts to the other points you made:
> >>>>>>>
> >>>>>>>> a) know that the slow queries logs exist,
> >>>>>>>
> >>>>>>> Hmm... If I take a look at the 1.x logging it was very
> >>>>>>> straightforward. As a developer you would spin up a CouchDB and you
> >>>>>>> get all the log messages into your terminal. It was quite handy in
> >>>>>>> general for all kind of debugging. That the logs are not displayed
> >>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
> >>>>>>> The
> >>>>>>> problem does occur with all kinds of log message we produce in
> >>>>>>> CouchDB
> >>>>>>> for 2.x and is not specific to the slow-query-logging.
> >>>>>>>
> >>>>>>>
> >>>>>>>> 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".
> >>>>>>>
> >>>>>>> I really like the migration path you mentioned here with the API to
> >>>>>>> create indexes. I am worried to have a too high entry barrier for
> >>>>>>> absolute newcomers, people that you want to play around before they
> >>>>>>> are ready to think about indexes, e.g. by putting coupling the
> >>>>>>> index
> >>>>>>> topic from the beginning to the querying.
> >>>>>>>
> >>>>>>> When I throw too much things to learn on people (which may not
> >>>>>>> have
> >>>>>>> used a database before), most people get discouraged and does not
> >>>>>>> take
> >>>>>>> a look. The usual things they feel or say are : "too complicated",
> >>>>>>> "I
> >>>>>>> have not enough time", "product XY is easier to use".
> >>>>>>>
> >>>>>>> I would argue that newcomers to a database will launch a high
> >>>>>>> traffic,
> >>>>>>> multi-gigabyte product with the database from day one. Day one is
> >>>>>>> the
> >>>>>>> day where they learn how to query the data and put data into the
> >>>>>>> database. Even for scenarios where people have a running high
> >>>>>>> traffic
> >>>>>>> system, and have used other databases at a medium to large scale I
> >>>>>>> would expect given they migrate to Couch, that they run both
> >>>>>>> systems
> >>>>>>> in parallel for the first time in order to fix the issues that
> >>>>>>> occur
> >>>>>>> during a migration.
> >>>>>>>
> >>>>>>> I think we we share the same goal (getting beginners started
> >>>>>>> quickly)
> >>>>>>> and the cool thing about your suggestion is that everyone gets the
> >>>>>>> required knowledge to run a production system right from the very
> >>>>>>> start. My suggestion leaves some parts out, but reduces the
> >>>>>>> cognitive
> >>>>>>> load required to get the very first basic results, e.g. in a
> >>>>>>> university class setting - or junior developers on their "casual
> >>>>>>> friday 20% time". My big hope is, once those folks build high
> >>>>>>> traffic
> >>>>>>> systems, they remember how easy the usage of CouchDB was and that
> >>>>>>> they
> >>>>>>> start to learn more about CouchDB in order to run it in a system
> >>>>>>> with
> >>>>>>> more than a few thousand documents.
> >>>>>>>
> >>>>>>>
> >>>>>>> For us both I think the "what" is clear, but the "how" is a bit
> >>>>>>> different. I also think this discussion still makes progress, but I
> >>>>>>> am
> >>>>>>> afraid it could stall. I see that we both have very good rudiments
> >>>>>>> and
> >>>>>>> I would like to invite the other folks from the mailing list that
> >>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
> >>>>>>> again
> >>>>>>> with their opinions - of course I'm also looking forward to your
> >>>>>>> answer :)
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> Robert :)
> >>>>>>>
> >>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
> >>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
> >>>>>>> wrote:
> >>>>>>>>>> - 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.
> >>>>>>>
> >>>>>>
> >>>>
> >>
>
>
Re: [POC] Mango Catch All Selector
Posted by Robert Kowalski <ro...@kowalski.gd>.
Hi Garren,
what would selector: null do? Return all docs?
Where in the answer from CouchDB would be the warning? Next to the
resultset, like
[{"_id": "foo", "_rev": "535"}, {"_warning": "slow query, use an index for
better performance"}] ?
Am Mittwoch, 13. Januar 2016 schrieb Garren Smith :
> Hi Robert,
>
> I think you miss understood me, I don’t want it to be a different endpoint.
> I just don’t want a user to have to do queries like this find({slow:
> true}). I want them to be able to do a query e.g. find({}) or
> find({selector: null}) and then get back the results along with a warning
> message telling them that this query would be slow in production.
> The lower the barrier for entry here the better. I know we want to protect
> our users for when they go to production, but forcing them to add a slow:
> true flag won’t help. It will still require them to read the docs a lot
> more than most people are willing to on a first attempt of something new.
>
> Cheers
> Garren
> > On 12 Jan 2016, at 9:16 PM, Robert Kowalski <rok@kowalski.gd
> <javascript:;>> wrote:
> >
> > thank you all for your feedback!
> >
> > i like the idea of the error message with a new url.
> >
> > i agree with garren that it should be a separate endpoint. it takes
> > some complexity off when explaining each endpoint.
> >
> > maybe: `/_find_slow`?
> >
> > On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <jan@apache.org
> <javascript:;>> wrote:
> >>
> >>> On 11 Jan 2016, at 19:55, Tony Sun <tony.sun427@gmail.com
> <javascript:;>> wrote:
> >>>
> >>> Hi Robert,
> >>>
> >>> Building upon what others have stated above, what do you think about
> >>> the following:
> >>>
> >>> 1) Let the user query without creating an index
> >>> 2) Return an error message with a new url that has
> >>> "slow/no_index/developer":true appended at the end. The message clearly
> >>> explains that this query will be slow, and that creating an index will
> be
> >>> more efficient. However, he or she can continue. The error message will
> >>> then have a link to point to our documentation.
> >>> 3) In Fauxton, there is a checkbox or button that also appends the
> >>> "slow/no_index/developer":true to the _find url. If the user clicks it,
> >>> then the same message pops up to notify the user.
> >>
> >>
> >> I like this!
> >>
> >>
> >> Jan
> >> --
> >>
> >>>
> >>>
> >>>
> >>> Tony
> >>>
> >>>
> >>>
> >>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <
> wickedgrey@gmail.com <javascript:;>>
> >>> wrote:
> >>>
> >>>> Just wanted to chime in here as a user - I've run into similar
> >>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
> >>>> where stuff I was working on went smoothly in dev, but stopped once
> >>>> real load was pushed through it (thankfully for me, that was in
> >>>> testing, rather than released to customers).
> >>>>
> >>>> It's a frustrating experience, and I don't think that a reputation for
> >>>> "works until you cross a threshold, and then it doesn't, but only in
> >>>> production" is a good thing to move towards.
> >>>>
> >>>> Perhaps something like adding a key to the returned data along the
> >>>> lines of "_slow_warning": "This query is going to be slow on large
> >>>> data sets. See http://..." in addition to the ?slow_warning=true
> query
> >>>> param (note that I'm calling it "slow_warning" in both places only to
> >>>> increase discoverability; without the url param, the no-index query
> >>>> wouldn't work at all). Bikeshed the name as needed.
> >>>>
> >>>> I'd like to see a lot more URLs in CouchDB error messages in general,
> >>>> actually - I would find it very useful when trying to determine what's
> >>>> going wrong to have a URL right there in the logs that I can get more
> >>>> information from.
> >>>>
> >>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wohali@apache.org
> <javascript:;>> wrote:
> >>>>> Hi Robert,
> >>>>>
> >>>>> I've been thinking about this one for the week or so, and I have a
> >>>>> simple suggestion:
> >>>>>
> >>>>> Add the query parameter slow=true to enable this behaviour.
> >>>>>
> >>>>> This meets all the original requirements:
> >>>>>
> >>>>> 1. It is not default behaviour
> >>>>> 2. You can grep the log files for the word 'slow' and find evidence
> >>>>> 3. There is a shorthand, simple way to enable the behaviour
> >>>>> 4. Any self-respecting developer will try to remove slow=true, find
> >>>>> a break, and be forced to learn about indexes
> >>>>> 5. It's a bit cheeky, which I think is kind of fun :D
> >>>>>
> >>>>> All the best,
> >>>>> Joan
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "William Edney" <bedney@technicalpursuit.com <javascript:;>>
> >>>>>> To: dev@couchdb.apache.org <javascript:;>
> >>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
> >>>>>> Subject: Re: [POC] Mango Catch All Selector
> >>>>>>
> >>>>>> Hi Robert -
> >>>>>>
> >>>>>> As a builder of UI, API and library code who has also done developer
> >>>>>> training on a variety of technologies, one simple fix might be go
> >>>>>> ahead and
> >>>>>> not require indexes to be built, but then to put a big NOTE at the
> >>>>>> beginning of the "Mango Getting Started" guide (I would assume there
> >>>>>> is
> >>>>>> such a piece of documentation) that states: "Note that the examples
> >>>>>> in this
> >>>>>> document do not require you to build an index, but for performance
> >>>>>> reasons
> >>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more
> information
> >>>>>> about
> >>>>>> how to do that" (or some such verbiage).
> >>>>>>
> >>>>>> My 2 cents.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> - Bill
> >>>>>>
> >>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <rok@kowalski.gd
> <javascript:;>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi list,
> >>>>>>>
> >>>>>>> At the end of the mail I would like to invite the other folks from
> >>>>>>> the
> >>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
> >>>>>>> UIs)
> >>>>>>> to chime in again with their opinions. So all people one the ML,
> >>>>>>> the
> >>>>>>> mail is not just a response to Paul, feedback is welcome :)
> >>>>>>>
> >>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
> >>>>>>> errors which are hard to debug and support.
> >>>>>>>
> >>>>>>> I added some thoughts to the other points you made:
> >>>>>>>
> >>>>>>>> a) know that the slow queries logs exist,
> >>>>>>>
> >>>>>>> Hmm... If I take a look at the 1.x logging it was very
> >>>>>>> straightforward. As a developer you would spin up a CouchDB and you
> >>>>>>> get all the log messages into your terminal. It was quite handy in
> >>>>>>> general for all kind of debugging. That the logs are not displayed
> >>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
> >>>>>>> The
> >>>>>>> problem does occur with all kinds of log message we produce in
> >>>>>>> CouchDB
> >>>>>>> for 2.x and is not specific to the slow-query-logging.
> >>>>>>>
> >>>>>>>
> >>>>>>>> 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".
> >>>>>>>
> >>>>>>> I really like the migration path you mentioned here with the API to
> >>>>>>> create indexes. I am worried to have a too high entry barrier for
> >>>>>>> absolute newcomers, people that you want to play around before they
> >>>>>>> are ready to think about indexes, e.g. by putting coupling the
> >>>>>>> index
> >>>>>>> topic from the beginning to the querying.
> >>>>>>>
> >>>>>>> When I throw too much things to learn on people (which may not
> >>>>>>> have
> >>>>>>> used a database before), most people get discouraged and does not
> >>>>>>> take
> >>>>>>> a look. The usual things they feel or say are : "too complicated",
> >>>>>>> "I
> >>>>>>> have not enough time", "product XY is easier to use".
> >>>>>>>
> >>>>>>> I would argue that newcomers to a database will launch a high
> >>>>>>> traffic,
> >>>>>>> multi-gigabyte product with the database from day one. Day one is
> >>>>>>> the
> >>>>>>> day where they learn how to query the data and put data into the
> >>>>>>> database. Even for scenarios where people have a running high
> >>>>>>> traffic
> >>>>>>> system, and have used other databases at a medium to large scale I
> >>>>>>> would expect given they migrate to Couch, that they run both
> >>>>>>> systems
> >>>>>>> in parallel for the first time in order to fix the issues that
> >>>>>>> occur
> >>>>>>> during a migration.
> >>>>>>>
> >>>>>>> I think we we share the same goal (getting beginners started
> >>>>>>> quickly)
> >>>>>>> and the cool thing about your suggestion is that everyone gets the
> >>>>>>> required knowledge to run a production system right from the very
> >>>>>>> start. My suggestion leaves some parts out, but reduces the
> >>>>>>> cognitive
> >>>>>>> load required to get the very first basic results, e.g. in a
> >>>>>>> university class setting - or junior developers on their "casual
> >>>>>>> friday 20% time". My big hope is, once those folks build high
> >>>>>>> traffic
> >>>>>>> systems, they remember how easy the usage of CouchDB was and that
> >>>>>>> they
> >>>>>>> start to learn more about CouchDB in order to run it in a system
> >>>>>>> with
> >>>>>>> more than a few thousand documents.
> >>>>>>>
> >>>>>>>
> >>>>>>> For us both I think the "what" is clear, but the "how" is a bit
> >>>>>>> different. I also think this discussion still makes progress, but I
> >>>>>>> am
> >>>>>>> afraid it could stall. I see that we both have very good rudiments
> >>>>>>> and
> >>>>>>> I would like to invite the other folks from the mailing list that
> >>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
> >>>>>>> again
> >>>>>>> with their opinions - of course I'm also looking forward to your
> >>>>>>> answer :)
> >>>>>>>
> >>>>>>> Best,
> >>>>>>> Robert :)
> >>>>>>>
> >>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
> >>>>>>> <paul.joseph.davis@gmail.com <javascript:;>>
> >>>>>>> wrote:
> >>>>>>>>>> - 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.
> >>>>>>>
> >>>>>>
> >>>>
> >>
>
>
Re: [POC] Mango Catch All Selector
Posted by Garren Smith <ga...@apache.org>.
Hi Robert,
I think you miss understood me, I don’t want it to be a different endpoint.
I just don’t want a user to have to do queries like this find({slow: true}). I want them to be able to do a query e.g. find({}) or find({selector: null}) and then get back the results along with a warning message telling them that this query would be slow in production.
The lower the barrier for entry here the better. I know we want to protect our users for when they go to production, but forcing them to add a slow: true flag won’t help. It will still require them to read the docs a lot more than most people are willing to on a first attempt of something new.
Cheers
Garren
> On 12 Jan 2016, at 9:16 PM, Robert Kowalski <ro...@kowalski.gd> wrote:
>
> thank you all for your feedback!
>
> i like the idea of the error message with a new url.
>
> i agree with garren that it should be a separate endpoint. it takes
> some complexity off when explaining each endpoint.
>
> maybe: `/_find_slow`?
>
> On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> On 11 Jan 2016, at 19:55, Tony Sun <to...@gmail.com> wrote:
>>>
>>> Hi Robert,
>>>
>>> Building upon what others have stated above, what do you think about
>>> the following:
>>>
>>> 1) Let the user query without creating an index
>>> 2) Return an error message with a new url that has
>>> "slow/no_index/developer":true appended at the end. The message clearly
>>> explains that this query will be slow, and that creating an index will be
>>> more efficient. However, he or she can continue. The error message will
>>> then have a link to point to our documentation.
>>> 3) In Fauxton, there is a checkbox or button that also appends the
>>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>>> then the same message pops up to notify the user.
>>
>>
>> I like this!
>>
>>
>> Jan
>> --
>>
>>>
>>>
>>>
>>> Tony
>>>
>>>
>>>
>>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <wi...@gmail.com>
>>> wrote:
>>>
>>>> Just wanted to chime in here as a user - I've run into similar
>>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>>> where stuff I was working on went smoothly in dev, but stopped once
>>>> real load was pushed through it (thankfully for me, that was in
>>>> testing, rather than released to customers).
>>>>
>>>> It's a frustrating experience, and I don't think that a reputation for
>>>> "works until you cross a threshold, and then it doesn't, but only in
>>>> production" is a good thing to move towards.
>>>>
>>>> Perhaps something like adding a key to the returned data along the
>>>> lines of "_slow_warning": "This query is going to be slow on large
>>>> data sets. See http://..." in addition to the ?slow_warning=true query
>>>> param (note that I'm calling it "slow_warning" in both places only to
>>>> increase discoverability; without the url param, the no-index query
>>>> wouldn't work at all). Bikeshed the name as needed.
>>>>
>>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>>> actually - I would find it very useful when trying to determine what's
>>>> going wrong to have a URL right there in the logs that I can get more
>>>> information from.
>>>>
>>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wo...@apache.org> wrote:
>>>>> Hi Robert,
>>>>>
>>>>> I've been thinking about this one for the week or so, and I have a
>>>>> simple suggestion:
>>>>>
>>>>> Add the query parameter slow=true to enable this behaviour.
>>>>>
>>>>> This meets all the original requirements:
>>>>>
>>>>> 1. It is not default behaviour
>>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>>> a break, and be forced to learn about indexes
>>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>>
>>>>> All the best,
>>>>> Joan
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "William Edney" <be...@technicalpursuit.com>
>>>>>> To: dev@couchdb.apache.org
>>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>>
>>>>>> Hi Robert -
>>>>>>
>>>>>> As a builder of UI, API and library code who has also done developer
>>>>>> training on a variety of technologies, one simple fix might be go
>>>>>> ahead and
>>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>>> is
>>>>>> such a piece of documentation) that states: "Note that the examples
>>>>>> in this
>>>>>> document do not require you to build an index, but for performance
>>>>>> reasons
>>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more information
>>>>>> about
>>>>>> how to do that" (or some such verbiage).
>>>>>>
>>>>>> My 2 cents.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> - Bill
>>>>>>
>>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi list,
>>>>>>>
>>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>>> the
>>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>>> UIs)
>>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>>> the
>>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>>
>>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>>> errors which are hard to debug and support.
>>>>>>>
>>>>>>> I added some thoughts to the other points you made:
>>>>>>>
>>>>>>>> a) know that the slow queries logs exist,
>>>>>>>
>>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>>> The
>>>>>>> problem does occur with all kinds of log message we produce in
>>>>>>> CouchDB
>>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>>
>>>>>>>
>>>>>>>> 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".
>>>>>>>
>>>>>>> I really like the migration path you mentioned here with the API to
>>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>>> absolute newcomers, people that you want to play around before they
>>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>>> index
>>>>>>> topic from the beginning to the querying.
>>>>>>>
>>>>>>> When I throw too much things to learn on people (which may not
>>>>>>> have
>>>>>>> used a database before), most people get discouraged and does not
>>>>>>> take
>>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>>> "I
>>>>>>> have not enough time", "product XY is easier to use".
>>>>>>>
>>>>>>> I would argue that newcomers to a database will launch a high
>>>>>>> traffic,
>>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>>> the
>>>>>>> day where they learn how to query the data and put data into the
>>>>>>> database. Even for scenarios where people have a running high
>>>>>>> traffic
>>>>>>> system, and have used other databases at a medium to large scale I
>>>>>>> would expect given they migrate to Couch, that they run both
>>>>>>> systems
>>>>>>> in parallel for the first time in order to fix the issues that
>>>>>>> occur
>>>>>>> during a migration.
>>>>>>>
>>>>>>> I think we we share the same goal (getting beginners started
>>>>>>> quickly)
>>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>>> required knowledge to run a production system right from the very
>>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>>> cognitive
>>>>>>> load required to get the very first basic results, e.g. in a
>>>>>>> university class setting - or junior developers on their "casual
>>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>>> traffic
>>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>>> they
>>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>>> with
>>>>>>> more than a few thousand documents.
>>>>>>>
>>>>>>>
>>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>>> different. I also think this discussion still makes progress, but I
>>>>>>> am
>>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>>> and
>>>>>>> I would like to invite the other folks from the mailing list that
>>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>>> again
>>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>>> answer :)
>>>>>>>
>>>>>>> Best,
>>>>>>> Robert :)
>>>>>>>
>>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>>> <pa...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>> - 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.
>>>>>>>
>>>>>>
>>>>
>>
Re: [POC] Mango Catch All Selector
Posted by Robert Kowalski <ro...@kowalski.gd>.
thank you all for your feedback!
i like the idea of the error message with a new url.
i agree with garren that it should be a separate endpoint. it takes
some complexity off when explaining each endpoint.
maybe: `/_find_slow`?
On Tue, Jan 12, 2016 at 10:36 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> On 11 Jan 2016, at 19:55, Tony Sun <to...@gmail.com> wrote:
>>
>> Hi Robert,
>>
>> Building upon what others have stated above, what do you think about
>> the following:
>>
>> 1) Let the user query without creating an index
>> 2) Return an error message with a new url that has
>> "slow/no_index/developer":true appended at the end. The message clearly
>> explains that this query will be slow, and that creating an index will be
>> more efficient. However, he or she can continue. The error message will
>> then have a link to point to our documentation.
>> 3) In Fauxton, there is a checkbox or button that also appends the
>> "slow/no_index/developer":true to the _find url. If the user clicks it,
>> then the same message pops up to notify the user.
>
>
> I like this!
>
>
> Jan
> --
>
>>
>>
>>
>> Tony
>>
>>
>>
>> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <wi...@gmail.com>
>> wrote:
>>
>>> Just wanted to chime in here as a user - I've run into similar
>>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>>> where stuff I was working on went smoothly in dev, but stopped once
>>> real load was pushed through it (thankfully for me, that was in
>>> testing, rather than released to customers).
>>>
>>> It's a frustrating experience, and I don't think that a reputation for
>>> "works until you cross a threshold, and then it doesn't, but only in
>>> production" is a good thing to move towards.
>>>
>>> Perhaps something like adding a key to the returned data along the
>>> lines of "_slow_warning": "This query is going to be slow on large
>>> data sets. See http://..." in addition to the ?slow_warning=true query
>>> param (note that I'm calling it "slow_warning" in both places only to
>>> increase discoverability; without the url param, the no-index query
>>> wouldn't work at all). Bikeshed the name as needed.
>>>
>>> I'd like to see a lot more URLs in CouchDB error messages in general,
>>> actually - I would find it very useful when trying to determine what's
>>> going wrong to have a URL right there in the logs that I can get more
>>> information from.
>>>
>>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wo...@apache.org> wrote:
>>>> Hi Robert,
>>>>
>>>> I've been thinking about this one for the week or so, and I have a
>>>> simple suggestion:
>>>>
>>>> Add the query parameter slow=true to enable this behaviour.
>>>>
>>>> This meets all the original requirements:
>>>>
>>>> 1. It is not default behaviour
>>>> 2. You can grep the log files for the word 'slow' and find evidence
>>>> 3. There is a shorthand, simple way to enable the behaviour
>>>> 4. Any self-respecting developer will try to remove slow=true, find
>>>> a break, and be forced to learn about indexes
>>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>>
>>>> All the best,
>>>> Joan
>>>>
>>>> ----- Original Message -----
>>>>> From: "William Edney" <be...@technicalpursuit.com>
>>>>> To: dev@couchdb.apache.org
>>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>>
>>>>> Hi Robert -
>>>>>
>>>>> As a builder of UI, API and library code who has also done developer
>>>>> training on a variety of technologies, one simple fix might be go
>>>>> ahead and
>>>>> not require indexes to be built, but then to put a big NOTE at the
>>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>>> is
>>>>> such a piece of documentation) that states: "Note that the examples
>>>>> in this
>>>>> document do not require you to build an index, but for performance
>>>>> reasons
>>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more information
>>>>> about
>>>>> how to do that" (or some such verbiage).
>>>>>
>>>>> My 2 cents.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> - Bill
>>>>>
>>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd>
>>>>> wrote:
>>>>>
>>>>>> Hi list,
>>>>>>
>>>>>> At the end of the mail I would like to invite the other folks from
>>>>>> the
>>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>>> UIs)
>>>>>> to chime in again with their opinions. So all people one the ML,
>>>>>> the
>>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>>
>>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>>> errors which are hard to debug and support.
>>>>>>
>>>>>> I added some thoughts to the other points you made:
>>>>>>
>>>>>>> a) know that the slow queries logs exist,
>>>>>>
>>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>>> get all the log messages into your terminal. It was quite handy in
>>>>>> general for all kind of debugging. That the logs are not displayed
>>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>>> The
>>>>>> problem does occur with all kinds of log message we produce in
>>>>>> CouchDB
>>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>>
>>>>>>
>>>>>>> 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".
>>>>>>
>>>>>> I really like the migration path you mentioned here with the API to
>>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>>> absolute newcomers, people that you want to play around before they
>>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>>> index
>>>>>> topic from the beginning to the querying.
>>>>>>
>>>>>> When I throw too much things to learn on people (which may not
>>>>>> have
>>>>>> used a database before), most people get discouraged and does not
>>>>>> take
>>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>>> "I
>>>>>> have not enough time", "product XY is easier to use".
>>>>>>
>>>>>> I would argue that newcomers to a database will launch a high
>>>>>> traffic,
>>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>>> the
>>>>>> day where they learn how to query the data and put data into the
>>>>>> database. Even for scenarios where people have a running high
>>>>>> traffic
>>>>>> system, and have used other databases at a medium to large scale I
>>>>>> would expect given they migrate to Couch, that they run both
>>>>>> systems
>>>>>> in parallel for the first time in order to fix the issues that
>>>>>> occur
>>>>>> during a migration.
>>>>>>
>>>>>> I think we we share the same goal (getting beginners started
>>>>>> quickly)
>>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>>> required knowledge to run a production system right from the very
>>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>>> cognitive
>>>>>> load required to get the very first basic results, e.g. in a
>>>>>> university class setting - or junior developers on their "casual
>>>>>> friday 20% time". My big hope is, once those folks build high
>>>>>> traffic
>>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>>> they
>>>>>> start to learn more about CouchDB in order to run it in a system
>>>>>> with
>>>>>> more than a few thousand documents.
>>>>>>
>>>>>>
>>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>>> different. I also think this discussion still makes progress, but I
>>>>>> am
>>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>>> and
>>>>>> I would like to invite the other folks from the mailing list that
>>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>>> again
>>>>>> with their opinions - of course I'm also looking forward to your
>>>>>> answer :)
>>>>>>
>>>>>> Best,
>>>>>> Robert :)
>>>>>>
>>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>>> <pa...@gmail.com>
>>>>>> wrote:
>>>>>>>>> - 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.
>>>>>>
>>>>>
>>>
>
Re: [POC] Mango Catch All Selector
Posted by Jan Lehnardt <ja...@apache.org>.
> On 11 Jan 2016, at 19:55, Tony Sun <to...@gmail.com> wrote:
>
> Hi Robert,
>
> Building upon what others have stated above, what do you think about
> the following:
>
> 1) Let the user query without creating an index
> 2) Return an error message with a new url that has
> "slow/no_index/developer":true appended at the end. The message clearly
> explains that this query will be slow, and that creating an index will be
> more efficient. However, he or she can continue. The error message will
> then have a link to point to our documentation.
> 3) In Fauxton, there is a checkbox or button that also appends the
> "slow/no_index/developer":true to the _find url. If the user clicks it,
> then the same message pops up to notify the user.
I like this!
Jan
--
>
>
>
> Tony
>
>
>
> On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <wi...@gmail.com>
> wrote:
>
>> Just wanted to chime in here as a user - I've run into similar
>> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
>> where stuff I was working on went smoothly in dev, but stopped once
>> real load was pushed through it (thankfully for me, that was in
>> testing, rather than released to customers).
>>
>> It's a frustrating experience, and I don't think that a reputation for
>> "works until you cross a threshold, and then it doesn't, but only in
>> production" is a good thing to move towards.
>>
>> Perhaps something like adding a key to the returned data along the
>> lines of "_slow_warning": "This query is going to be slow on large
>> data sets. See http://..." in addition to the ?slow_warning=true query
>> param (note that I'm calling it "slow_warning" in both places only to
>> increase discoverability; without the url param, the no-index query
>> wouldn't work at all). Bikeshed the name as needed.
>>
>> I'd like to see a lot more URLs in CouchDB error messages in general,
>> actually - I would find it very useful when trying to determine what's
>> going wrong to have a URL right there in the logs that I can get more
>> information from.
>>
>> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wo...@apache.org> wrote:
>>> Hi Robert,
>>>
>>> I've been thinking about this one for the week or so, and I have a
>>> simple suggestion:
>>>
>>> Add the query parameter slow=true to enable this behaviour.
>>>
>>> This meets all the original requirements:
>>>
>>> 1. It is not default behaviour
>>> 2. You can grep the log files for the word 'slow' and find evidence
>>> 3. There is a shorthand, simple way to enable the behaviour
>>> 4. Any self-respecting developer will try to remove slow=true, find
>>> a break, and be forced to learn about indexes
>>> 5. It's a bit cheeky, which I think is kind of fun :D
>>>
>>> All the best,
>>> Joan
>>>
>>> ----- Original Message -----
>>>> From: "William Edney" <be...@technicalpursuit.com>
>>>> To: dev@couchdb.apache.org
>>>> Sent: Friday, January 8, 2016 10:27:29 AM
>>>> Subject: Re: [POC] Mango Catch All Selector
>>>>
>>>> Hi Robert -
>>>>
>>>> As a builder of UI, API and library code who has also done developer
>>>> training on a variety of technologies, one simple fix might be go
>>>> ahead and
>>>> not require indexes to be built, but then to put a big NOTE at the
>>>> beginning of the "Mango Getting Started" guide (I would assume there
>>>> is
>>>> such a piece of documentation) that states: "Note that the examples
>>>> in this
>>>> document do not require you to build an index, but for performance
>>>> reasons
>>>> we HIGHLY RECOMMEND that you do so. *Click here* for more information
>>>> about
>>>> how to do that" (or some such verbiage).
>>>>
>>>> My 2 cents.
>>>>
>>>> Cheers,
>>>>
>>>> - Bill
>>>>
>>>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd>
>>>> wrote:
>>>>
>>>>> Hi list,
>>>>>
>>>>> At the end of the mail I would like to invite the other folks from
>>>>> the
>>>>> mailing list that build interfaces for humans (APIs, CLIs or even
>>>>> UIs)
>>>>> to chime in again with their opinions. So all people one the ML,
>>>>> the
>>>>> mail is not just a response to Paul, feedback is welcome :)
>>>>>
>>>>> Hi Paul, I agree with the timeout. It could lead to very unpleasant
>>>>> errors which are hard to debug and support.
>>>>>
>>>>> I added some thoughts to the other points you made:
>>>>>
>>>>>> a) know that the slow queries logs exist,
>>>>>
>>>>> Hmm... If I take a look at the 1.x logging it was very
>>>>> straightforward. As a developer you would spin up a CouchDB and you
>>>>> get all the log messages into your terminal. It was quite handy in
>>>>> general for all kind of debugging. That the logs are not displayed
>>>>> directly on stdout/stderr is in my opinion a general 2.x problem.
>>>>> The
>>>>> problem does occur with all kinds of log message we produce in
>>>>> CouchDB
>>>>> for 2.x and is not specific to the slow-query-logging.
>>>>>
>>>>>
>>>>>> 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".
>>>>>
>>>>> I really like the migration path you mentioned here with the API to
>>>>> create indexes. I am worried to have a too high entry barrier for
>>>>> absolute newcomers, people that you want to play around before they
>>>>> are ready to think about indexes, e.g. by putting coupling the
>>>>> index
>>>>> topic from the beginning to the querying.
>>>>>
>>>>> When I throw too much things to learn on people (which may not
>>>>> have
>>>>> used a database before), most people get discouraged and does not
>>>>> take
>>>>> a look. The usual things they feel or say are : "too complicated",
>>>>> "I
>>>>> have not enough time", "product XY is easier to use".
>>>>>
>>>>> I would argue that newcomers to a database will launch a high
>>>>> traffic,
>>>>> multi-gigabyte product with the database from day one. Day one is
>>>>> the
>>>>> day where they learn how to query the data and put data into the
>>>>> database. Even for scenarios where people have a running high
>>>>> traffic
>>>>> system, and have used other databases at a medium to large scale I
>>>>> would expect given they migrate to Couch, that they run both
>>>>> systems
>>>>> in parallel for the first time in order to fix the issues that
>>>>> occur
>>>>> during a migration.
>>>>>
>>>>> I think we we share the same goal (getting beginners started
>>>>> quickly)
>>>>> and the cool thing about your suggestion is that everyone gets the
>>>>> required knowledge to run a production system right from the very
>>>>> start. My suggestion leaves some parts out, but reduces the
>>>>> cognitive
>>>>> load required to get the very first basic results, e.g. in a
>>>>> university class setting - or junior developers on their "casual
>>>>> friday 20% time". My big hope is, once those folks build high
>>>>> traffic
>>>>> systems, they remember how easy the usage of CouchDB was and that
>>>>> they
>>>>> start to learn more about CouchDB in order to run it in a system
>>>>> with
>>>>> more than a few thousand documents.
>>>>>
>>>>>
>>>>> For us both I think the "what" is clear, but the "how" is a bit
>>>>> different. I also think this discussion still makes progress, but I
>>>>> am
>>>>> afraid it could stall. I see that we both have very good rudiments
>>>>> and
>>>>> I would like to invite the other folks from the mailing list that
>>>>> build interfaces for humans (APIs, CLIs or even UIs) to chime in
>>>>> again
>>>>> with their opinions - of course I'm also looking forward to your
>>>>> answer :)
>>>>>
>>>>> Best,
>>>>> Robert :)
>>>>>
>>>>> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>>>>> <pa...@gmail.com>
>>>>> wrote:
>>>>>>>> - 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.
>>>>>
>>>>
>>
Re: [POC] Mango Catch All Selector
Posted by Tony Sun <to...@gmail.com>.
Hi Robert,
Building upon what others have stated above, what do you think about
the following:
1) Let the user query without creating an index
2) Return an error message with a new url that has
"slow/no_index/developer":true appended at the end. The message clearly
explains that this query will be slow, and that creating an index will be
more efficient. However, he or she can continue. The error message will
then have a link to point to our documentation.
3) In Fauxton, there is a checkbox or button that also appends the
"slow/no_index/developer":true to the _find url. If the user clicks it,
then the same message pops up to notify the user.
Tony
On Mon, Jan 11, 2016 at 9:45 AM, Eli Stevens (Gmail) <wi...@gmail.com>
wrote:
> Just wanted to chime in here as a user - I've run into similar
> behavior from CouchDB with the reduce-not-reducing-enough heuristic,
> where stuff I was working on went smoothly in dev, but stopped once
> real load was pushed through it (thankfully for me, that was in
> testing, rather than released to customers).
>
> It's a frustrating experience, and I don't think that a reputation for
> "works until you cross a threshold, and then it doesn't, but only in
> production" is a good thing to move towards.
>
> Perhaps something like adding a key to the returned data along the
> lines of "_slow_warning": "This query is going to be slow on large
> data sets. See http://..." in addition to the ?slow_warning=true query
> param (note that I'm calling it "slow_warning" in both places only to
> increase discoverability; without the url param, the no-index query
> wouldn't work at all). Bikeshed the name as needed.
>
> I'd like to see a lot more URLs in CouchDB error messages in general,
> actually - I would find it very useful when trying to determine what's
> going wrong to have a URL right there in the logs that I can get more
> information from.
>
> On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wo...@apache.org> wrote:
> > Hi Robert,
> >
> > I've been thinking about this one for the week or so, and I have a
> > simple suggestion:
> >
> > Add the query parameter slow=true to enable this behaviour.
> >
> > This meets all the original requirements:
> >
> > 1. It is not default behaviour
> > 2. You can grep the log files for the word 'slow' and find evidence
> > 3. There is a shorthand, simple way to enable the behaviour
> > 4. Any self-respecting developer will try to remove slow=true, find
> > a break, and be forced to learn about indexes
> > 5. It's a bit cheeky, which I think is kind of fun :D
> >
> > All the best,
> > Joan
> >
> > ----- Original Message -----
> >> From: "William Edney" <be...@technicalpursuit.com>
> >> To: dev@couchdb.apache.org
> >> Sent: Friday, January 8, 2016 10:27:29 AM
> >> Subject: Re: [POC] Mango Catch All Selector
> >>
> >> Hi Robert -
> >>
> >> As a builder of UI, API and library code who has also done developer
> >> training on a variety of technologies, one simple fix might be go
> >> ahead and
> >> not require indexes to be built, but then to put a big NOTE at the
> >> beginning of the "Mango Getting Started" guide (I would assume there
> >> is
> >> such a piece of documentation) that states: "Note that the examples
> >> in this
> >> document do not require you to build an index, but for performance
> >> reasons
> >> we HIGHLY RECOMMEND that you do so. *Click here* for more information
> >> about
> >> how to do that" (or some such verbiage).
> >>
> >> My 2 cents.
> >>
> >> Cheers,
> >>
> >> - Bill
> >>
> >> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd>
> >> wrote:
> >>
> >> > Hi list,
> >> >
> >> > At the end of the mail I would like to invite the other folks from
> >> > the
> >> > mailing list that build interfaces for humans (APIs, CLIs or even
> >> > UIs)
> >> > to chime in again with their opinions. So all people one the ML,
> >> > the
> >> > mail is not just a response to Paul, feedback is welcome :)
> >> >
> >> > Hi Paul, I agree with the timeout. It could lead to very unpleasant
> >> > errors which are hard to debug and support.
> >> >
> >> > I added some thoughts to the other points you made:
> >> >
> >> > > a) know that the slow queries logs exist,
> >> >
> >> > Hmm... If I take a look at the 1.x logging it was very
> >> > straightforward. As a developer you would spin up a CouchDB and you
> >> > get all the log messages into your terminal. It was quite handy in
> >> > general for all kind of debugging. That the logs are not displayed
> >> > directly on stdout/stderr is in my opinion a general 2.x problem.
> >> > The
> >> > problem does occur with all kinds of log message we produce in
> >> > CouchDB
> >> > for 2.x and is not specific to the slow-query-logging.
> >> >
> >> >
> >> > > 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".
> >> >
> >> > I really like the migration path you mentioned here with the API to
> >> > create indexes. I am worried to have a too high entry barrier for
> >> > absolute newcomers, people that you want to play around before they
> >> > are ready to think about indexes, e.g. by putting coupling the
> >> > index
> >> > topic from the beginning to the querying.
> >> >
> >> > When I throw too much things to learn on people (which may not
> >> > have
> >> > used a database before), most people get discouraged and does not
> >> > take
> >> > a look. The usual things they feel or say are : "too complicated",
> >> > "I
> >> > have not enough time", "product XY is easier to use".
> >> >
> >> > I would argue that newcomers to a database will launch a high
> >> > traffic,
> >> > multi-gigabyte product with the database from day one. Day one is
> >> > the
> >> > day where they learn how to query the data and put data into the
> >> > database. Even for scenarios where people have a running high
> >> > traffic
> >> > system, and have used other databases at a medium to large scale I
> >> > would expect given they migrate to Couch, that they run both
> >> > systems
> >> > in parallel for the first time in order to fix the issues that
> >> > occur
> >> > during a migration.
> >> >
> >> > I think we we share the same goal (getting beginners started
> >> > quickly)
> >> > and the cool thing about your suggestion is that everyone gets the
> >> > required knowledge to run a production system right from the very
> >> > start. My suggestion leaves some parts out, but reduces the
> >> > cognitive
> >> > load required to get the very first basic results, e.g. in a
> >> > university class setting - or junior developers on their "casual
> >> > friday 20% time". My big hope is, once those folks build high
> >> > traffic
> >> > systems, they remember how easy the usage of CouchDB was and that
> >> > they
> >> > start to learn more about CouchDB in order to run it in a system
> >> > with
> >> > more than a few thousand documents.
> >> >
> >> >
> >> > For us both I think the "what" is clear, but the "how" is a bit
> >> > different. I also think this discussion still makes progress, but I
> >> > am
> >> > afraid it could stall. I see that we both have very good rudiments
> >> > and
> >> > I would like to invite the other folks from the mailing list that
> >> > build interfaces for humans (APIs, CLIs or even UIs) to chime in
> >> > again
> >> > with their opinions - of course I'm also looking forward to your
> >> > answer :)
> >> >
> >> > Best,
> >> > Robert :)
> >> >
> >> > On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
> >> > <pa...@gmail.com>
> >> > wrote:
> >> > >>> - 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.
> >> >
> >>
>
Re: [POC] Mango Catch All Selector
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
Just wanted to chime in here as a user - I've run into similar
behavior from CouchDB with the reduce-not-reducing-enough heuristic,
where stuff I was working on went smoothly in dev, but stopped once
real load was pushed through it (thankfully for me, that was in
testing, rather than released to customers).
It's a frustrating experience, and I don't think that a reputation for
"works until you cross a threshold, and then it doesn't, but only in
production" is a good thing to move towards.
Perhaps something like adding a key to the returned data along the
lines of "_slow_warning": "This query is going to be slow on large
data sets. See http://..." in addition to the ?slow_warning=true query
param (note that I'm calling it "slow_warning" in both places only to
increase discoverability; without the url param, the no-index query
wouldn't work at all). Bikeshed the name as needed.
I'd like to see a lot more URLs in CouchDB error messages in general,
actually - I would find it very useful when trying to determine what's
going wrong to have a URL right there in the logs that I can get more
information from.
On Sun, Jan 10, 2016 at 11:54 AM, Joan Touzet <wo...@apache.org> wrote:
> Hi Robert,
>
> I've been thinking about this one for the week or so, and I have a
> simple suggestion:
>
> Add the query parameter slow=true to enable this behaviour.
>
> This meets all the original requirements:
>
> 1. It is not default behaviour
> 2. You can grep the log files for the word 'slow' and find evidence
> 3. There is a shorthand, simple way to enable the behaviour
> 4. Any self-respecting developer will try to remove slow=true, find
> a break, and be forced to learn about indexes
> 5. It's a bit cheeky, which I think is kind of fun :D
>
> All the best,
> Joan
>
> ----- Original Message -----
>> From: "William Edney" <be...@technicalpursuit.com>
>> To: dev@couchdb.apache.org
>> Sent: Friday, January 8, 2016 10:27:29 AM
>> Subject: Re: [POC] Mango Catch All Selector
>>
>> Hi Robert -
>>
>> As a builder of UI, API and library code who has also done developer
>> training on a variety of technologies, one simple fix might be go
>> ahead and
>> not require indexes to be built, but then to put a big NOTE at the
>> beginning of the "Mango Getting Started" guide (I would assume there
>> is
>> such a piece of documentation) that states: "Note that the examples
>> in this
>> document do not require you to build an index, but for performance
>> reasons
>> we HIGHLY RECOMMEND that you do so. *Click here* for more information
>> about
>> how to do that" (or some such verbiage).
>>
>> My 2 cents.
>>
>> Cheers,
>>
>> - Bill
>>
>> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd>
>> wrote:
>>
>> > Hi list,
>> >
>> > At the end of the mail I would like to invite the other folks from
>> > the
>> > mailing list that build interfaces for humans (APIs, CLIs or even
>> > UIs)
>> > to chime in again with their opinions. So all people one the ML,
>> > the
>> > mail is not just a response to Paul, feedback is welcome :)
>> >
>> > Hi Paul, I agree with the timeout. It could lead to very unpleasant
>> > errors which are hard to debug and support.
>> >
>> > I added some thoughts to the other points you made:
>> >
>> > > a) know that the slow queries logs exist,
>> >
>> > Hmm... If I take a look at the 1.x logging it was very
>> > straightforward. As a developer you would spin up a CouchDB and you
>> > get all the log messages into your terminal. It was quite handy in
>> > general for all kind of debugging. That the logs are not displayed
>> > directly on stdout/stderr is in my opinion a general 2.x problem.
>> > The
>> > problem does occur with all kinds of log message we produce in
>> > CouchDB
>> > for 2.x and is not specific to the slow-query-logging.
>> >
>> >
>> > > 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".
>> >
>> > I really like the migration path you mentioned here with the API to
>> > create indexes. I am worried to have a too high entry barrier for
>> > absolute newcomers, people that you want to play around before they
>> > are ready to think about indexes, e.g. by putting coupling the
>> > index
>> > topic from the beginning to the querying.
>> >
>> > When I throw too much things to learn on people (which may not
>> > have
>> > used a database before), most people get discouraged and does not
>> > take
>> > a look. The usual things they feel or say are : "too complicated",
>> > "I
>> > have not enough time", "product XY is easier to use".
>> >
>> > I would argue that newcomers to a database will launch a high
>> > traffic,
>> > multi-gigabyte product with the database from day one. Day one is
>> > the
>> > day where they learn how to query the data and put data into the
>> > database. Even for scenarios where people have a running high
>> > traffic
>> > system, and have used other databases at a medium to large scale I
>> > would expect given they migrate to Couch, that they run both
>> > systems
>> > in parallel for the first time in order to fix the issues that
>> > occur
>> > during a migration.
>> >
>> > I think we we share the same goal (getting beginners started
>> > quickly)
>> > and the cool thing about your suggestion is that everyone gets the
>> > required knowledge to run a production system right from the very
>> > start. My suggestion leaves some parts out, but reduces the
>> > cognitive
>> > load required to get the very first basic results, e.g. in a
>> > university class setting - or junior developers on their "casual
>> > friday 20% time". My big hope is, once those folks build high
>> > traffic
>> > systems, they remember how easy the usage of CouchDB was and that
>> > they
>> > start to learn more about CouchDB in order to run it in a system
>> > with
>> > more than a few thousand documents.
>> >
>> >
>> > For us both I think the "what" is clear, but the "how" is a bit
>> > different. I also think this discussion still makes progress, but I
>> > am
>> > afraid it could stall. I see that we both have very good rudiments
>> > and
>> > I would like to invite the other folks from the mailing list that
>> > build interfaces for humans (APIs, CLIs or even UIs) to chime in
>> > again
>> > with their opinions - of course I'm also looking forward to your
>> > answer :)
>> >
>> > Best,
>> > Robert :)
>> >
>> > On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
>> > <pa...@gmail.com>
>> > wrote:
>> > >>> - 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.
>> >
>>
Re: [POC] Mango Catch All Selector
Posted by Joan Touzet <wo...@apache.org>.
Hi Robert,
I've been thinking about this one for the week or so, and I have a
simple suggestion:
Add the query parameter slow=true to enable this behaviour.
This meets all the original requirements:
1. It is not default behaviour
2. You can grep the log files for the word 'slow' and find evidence
3. There is a shorthand, simple way to enable the behaviour
4. Any self-respecting developer will try to remove slow=true, find
a break, and be forced to learn about indexes
5. It's a bit cheeky, which I think is kind of fun :D
All the best,
Joan
----- Original Message -----
> From: "William Edney" <be...@technicalpursuit.com>
> To: dev@couchdb.apache.org
> Sent: Friday, January 8, 2016 10:27:29 AM
> Subject: Re: [POC] Mango Catch All Selector
>
> Hi Robert -
>
> As a builder of UI, API and library code who has also done developer
> training on a variety of technologies, one simple fix might be go
> ahead and
> not require indexes to be built, but then to put a big NOTE at the
> beginning of the "Mango Getting Started" guide (I would assume there
> is
> such a piece of documentation) that states: "Note that the examples
> in this
> document do not require you to build an index, but for performance
> reasons
> we HIGHLY RECOMMEND that you do so. *Click here* for more information
> about
> how to do that" (or some such verbiage).
>
> My 2 cents.
>
> Cheers,
>
> - Bill
>
> On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd>
> wrote:
>
> > Hi list,
> >
> > At the end of the mail I would like to invite the other folks from
> > the
> > mailing list that build interfaces for humans (APIs, CLIs or even
> > UIs)
> > to chime in again with their opinions. So all people one the ML,
> > the
> > mail is not just a response to Paul, feedback is welcome :)
> >
> > Hi Paul, I agree with the timeout. It could lead to very unpleasant
> > errors which are hard to debug and support.
> >
> > I added some thoughts to the other points you made:
> >
> > > a) know that the slow queries logs exist,
> >
> > Hmm... If I take a look at the 1.x logging it was very
> > straightforward. As a developer you would spin up a CouchDB and you
> > get all the log messages into your terminal. It was quite handy in
> > general for all kind of debugging. That the logs are not displayed
> > directly on stdout/stderr is in my opinion a general 2.x problem.
> > The
> > problem does occur with all kinds of log message we produce in
> > CouchDB
> > for 2.x and is not specific to the slow-query-logging.
> >
> >
> > > 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".
> >
> > I really like the migration path you mentioned here with the API to
> > create indexes. I am worried to have a too high entry barrier for
> > absolute newcomers, people that you want to play around before they
> > are ready to think about indexes, e.g. by putting coupling the
> > index
> > topic from the beginning to the querying.
> >
> > When I throw too much things to learn on people (which may not
> > have
> > used a database before), most people get discouraged and does not
> > take
> > a look. The usual things they feel or say are : "too complicated",
> > "I
> > have not enough time", "product XY is easier to use".
> >
> > I would argue that newcomers to a database will launch a high
> > traffic,
> > multi-gigabyte product with the database from day one. Day one is
> > the
> > day where they learn how to query the data and put data into the
> > database. Even for scenarios where people have a running high
> > traffic
> > system, and have used other databases at a medium to large scale I
> > would expect given they migrate to Couch, that they run both
> > systems
> > in parallel for the first time in order to fix the issues that
> > occur
> > during a migration.
> >
> > I think we we share the same goal (getting beginners started
> > quickly)
> > and the cool thing about your suggestion is that everyone gets the
> > required knowledge to run a production system right from the very
> > start. My suggestion leaves some parts out, but reduces the
> > cognitive
> > load required to get the very first basic results, e.g. in a
> > university class setting - or junior developers on their "casual
> > friday 20% time". My big hope is, once those folks build high
> > traffic
> > systems, they remember how easy the usage of CouchDB was and that
> > they
> > start to learn more about CouchDB in order to run it in a system
> > with
> > more than a few thousand documents.
> >
> >
> > For us both I think the "what" is clear, but the "how" is a bit
> > different. I also think this discussion still makes progress, but I
> > am
> > afraid it could stall. I see that we both have very good rudiments
> > and
> > I would like to invite the other folks from the mailing list that
> > build interfaces for humans (APIs, CLIs or even UIs) to chime in
> > again
> > with their opinions - of course I'm also looking forward to your
> > answer :)
> >
> > Best,
> > Robert :)
> >
> > On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis
> > <pa...@gmail.com>
> > wrote:
> > >>> - 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.
> >
>
Re: [POC] Mango Catch All Selector
Posted by William Edney <be...@technicalpursuit.com>.
Hi Robert -
As a builder of UI, API and library code who has also done developer
training on a variety of technologies, one simple fix might be go ahead and
not require indexes to be built, but then to put a big NOTE at the
beginning of the "Mango Getting Started" guide (I would assume there is
such a piece of documentation) that states: "Note that the examples in this
document do not require you to build an index, but for performance reasons
we HIGHLY RECOMMEND that you do so. *Click here* for more information about
how to do that" (or some such verbiage).
My 2 cents.
Cheers,
- Bill
On Fri, Jan 8, 2016 at 9:04 AM, Robert Kowalski <ro...@kowalski.gd> wrote:
> Hi list,
>
> At the end of the mail I would like to invite the other folks from the
> mailing list that build interfaces for humans (APIs, CLIs or even UIs)
> to chime in again with their opinions. So all people one the ML, the
> mail is not just a response to Paul, feedback is welcome :)
>
> Hi Paul, I agree with the timeout. It could lead to very unpleasant
> errors which are hard to debug and support.
>
> I added some thoughts to the other points you made:
>
> > a) know that the slow queries logs exist,
>
> Hmm... If I take a look at the 1.x logging it was very
> straightforward. As a developer you would spin up a CouchDB and you
> get all the log messages into your terminal. It was quite handy in
> general for all kind of debugging. That the logs are not displayed
> directly on stdout/stderr is in my opinion a general 2.x problem. The
> problem does occur with all kinds of log message we produce in CouchDB
> for 2.x and is not specific to the slow-query-logging.
>
>
> > 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".
>
> I really like the migration path you mentioned here with the API to
> create indexes. I am worried to have a too high entry barrier for
> absolute newcomers, people that you want to play around before they
> are ready to think about indexes, e.g. by putting coupling the index
> topic from the beginning to the querying.
>
> When I throw too much things to learn on people (which may not have
> used a database before), most people get discouraged and does not take
> a look. The usual things they feel or say are : "too complicated", "I
> have not enough time", "product XY is easier to use".
>
> I would argue that newcomers to a database will launch a high traffic,
> multi-gigabyte product with the database from day one. Day one is the
> day where they learn how to query the data and put data into the
> database. Even for scenarios where people have a running high traffic
> system, and have used other databases at a medium to large scale I
> would expect given they migrate to Couch, that they run both systems
> in parallel for the first time in order to fix the issues that occur
> during a migration.
>
> I think we we share the same goal (getting beginners started quickly)
> and the cool thing about your suggestion is that everyone gets the
> required knowledge to run a production system right from the very
> start. My suggestion leaves some parts out, but reduces the cognitive
> load required to get the very first basic results, e.g. in a
> university class setting - or junior developers on their "casual
> friday 20% time". My big hope is, once those folks build high traffic
> systems, they remember how easy the usage of CouchDB was and that they
> start to learn more about CouchDB in order to run it in a system with
> more than a few thousand documents.
>
>
> For us both I think the "what" is clear, but the "how" is a bit
> different. I also think this discussion still makes progress, but I am
> afraid it could stall. I see that we both have very good rudiments and
> I would like to invite the other folks from the mailing list that
> build interfaces for humans (APIs, CLIs or even UIs) to chime in again
> with their opinions - of course I'm also looking forward to your
> answer :)
>
> Best,
> Robert :)
>
> On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis <pa...@gmail.com>
> wrote:
> >>> - 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.
>
Re: [POC] Mango Catch All Selector
Posted by Robert Kowalski <ro...@kowalski.gd>.
Hi list,
At the end of the mail I would like to invite the other folks from the
mailing list that build interfaces for humans (APIs, CLIs or even UIs)
to chime in again with their opinions. So all people one the ML, the
mail is not just a response to Paul, feedback is welcome :)
Hi Paul, I agree with the timeout. It could lead to very unpleasant
errors which are hard to debug and support.
I added some thoughts to the other points you made:
> a) know that the slow queries logs exist,
Hmm... If I take a look at the 1.x logging it was very
straightforward. As a developer you would spin up a CouchDB and you
get all the log messages into your terminal. It was quite handy in
general for all kind of debugging. That the logs are not displayed
directly on stdout/stderr is in my opinion a general 2.x problem. The
problem does occur with all kinds of log message we produce in CouchDB
for 2.x and is not specific to the slow-query-logging.
> 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".
I really like the migration path you mentioned here with the API to
create indexes. I am worried to have a too high entry barrier for
absolute newcomers, people that you want to play around before they
are ready to think about indexes, e.g. by putting coupling the index
topic from the beginning to the querying.
When I throw too much things to learn on people (which may not have
used a database before), most people get discouraged and does not take
a look. The usual things they feel or say are : "too complicated", "I
have not enough time", "product XY is easier to use".
I would argue that newcomers to a database will launch a high traffic,
multi-gigabyte product with the database from day one. Day one is the
day where they learn how to query the data and put data into the
database. Even for scenarios where people have a running high traffic
system, and have used other databases at a medium to large scale I
would expect given they migrate to Couch, that they run both systems
in parallel for the first time in order to fix the issues that occur
during a migration.
I think we we share the same goal (getting beginners started quickly)
and the cool thing about your suggestion is that everyone gets the
required knowledge to run a production system right from the very
start. My suggestion leaves some parts out, but reduces the cognitive
load required to get the very first basic results, e.g. in a
university class setting - or junior developers on their "casual
friday 20% time". My big hope is, once those folks build high traffic
systems, they remember how easy the usage of CouchDB was and that they
start to learn more about CouchDB in order to run it in a system with
more than a few thousand documents.
For us both I think the "what" is clear, but the "how" is a bit
different. I also think this discussion still makes progress, but I am
afraid it could stall. I see that we both have very good rudiments and
I would like to invite the other folks from the mailing list that
build interfaces for humans (APIs, CLIs or even UIs) to chime in again
with their opinions - of course I'm also looking forward to your
answer :)
Best,
Robert :)
On Wed, Jan 6, 2016 at 6:21 PM, Paul Davis <pa...@gmail.com> wrote:
>>> - 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.
Re: [POC] Mango Catch All Selector
Posted by Paul Davis <pa...@gmail.com>.
>> - 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.
Re: [POC] Mango Catch All Selector
Posted by Klaus Trainer <kl...@posteo.de>.
On 01/05/2016 12:52 PM, Robert Kowalski wrote:
> Summary of my open questions:
>
> - do you agree that users don't have enough tooling / insight to
> notice those problems? Should we handle query performance optimisation
> as a separate problem from using _all_docs as it can happen in more
> cases?
Having (warning?) log messages for slow queries (as suggested) would
already make a great improvement on its own.
Right now I don't know if, and if yes, in what kind of situations I'd
like to have warnings about _all_docs usage, so I'd tend to keep that
separate for now. No big opinion here, though.
> - how can we document Mango better, or at all? Any volunteers?
Sebastian and me have decided that the next CouchDB Hamburg meetup will
be more of the workshop type (i.e., less talk, more action), see
http://www.meetup.com/CouchDB-Meetup-Hamburg/events/226859021/
The topic will be Mango, and we're going to try it out and kick off some
documentation.
> - 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).
Re: [POC] Mango Catch All Selector
Posted by Robert Kowalski <ro...@kowalski.gd>.
Hi there!
Thanks for the detailed responses Garren, Paul, Sebastian, Dale and
Tony! It looks like that we have consensus that it should be easier to
query data with Mango. :)
I like the idea with the automatic index creation, probably just if
the user opts in, as I also think that index creation needs more
planning. Automatic index creation is probably another whole topic on
its own I am afraid, I would like to talk about it separately.
Regarding querying I would really like to keep it very simple for
newcomers and implement the "fallback" as transparent as possible.
A newcomer usually doesn't have much data in their databases when they
start to try out a new database system and play around. I agree with
Paul that the current behaviour is different from Mongo and also from
other successful databases (e.g. MySQL and Postgres). They all let you
query without indexes, but you can add them later for performance
optimisation. I feel unsuer about developing: true. Adding
"developing: true" or other parameters deviates further from those
systems which are very friendly to beginners, I would like to avoid
that.
I want to add that for more advanced production use cases the other
DBMS usually offer performance measuring tools, here is Mongo
https://docs.mongodb.org/manual/tutorial/manage-the-database-profiler/
and here is MySQL
http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html as examples
to help the user to detect slow queries and to optimise them. Rails
(is it still called Active Record?) will also explain and warn on slow
queries without index:
http://weblog.rubyonrails.org/2011/12/6/what-s-new-in-edge-rails-explain/
Maybe the mentioned problem for people that complain about slow
responses because they use the sometimes advertised id > null hack is
that they don't have enough tooling / insight to notice those
problems? Then this would be probably another task, something along
the lines of "improve query optimisation capabilities for users".
The idea I had for now is to log slow queries in the logfile. From
there monitoring tools etc could pick it up and inform the user in
some way if they don't run Couch on their own machine. The
documentation (right now Mango has no docs at all for CouchDB) should
basically explain that it runs out of the box, but if people go into
production, they should create indexes. (see also
https://docs.mongodb.org/manual/core/indexes-introduction/ which does
that quite nice).
I think the timeout for queries is a good idea. It could be also
configurable from the HTTP client. When the timeout is hit we could
inform the user that we think an index would be a better fit and maybe
even give them the curl command to create the index in the error
message, and also that they can raise the current timeout of X sec
using ?timeout=[newtimeout]. I have to confess that I am right now
just assuming how our users would use it and if they need a timeout.
Right now I am not sure if the timeout solves the root cause of the
problem or the symptoms. Do they want a query optimisation tool or
something else that helps them to explain why their queries are slow?
(see also section "improve query optimisation capabilities for users")
Summary of my open questions:
- do you agree that users don't have enough tooling / insight to
notice those problems? Should we handle query performance optimisation
as a separate problem from using _all_docs as it can happen in more
cases?
- how can we document Mango better, or at all? Any volunteers?
- 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?
On Mon, Jan 4, 2016 at 9:55 PM, Tony Sun <to...@gmail.com> wrote:
> Hi all,
>
> Hope everyone enjoyed the holidays!
>
> This is the most common mango experience for new users:
>
> 1) Syntax issues to create an index.
> 2) Running into the "no index found" error because his or her query
> (with and w/o sort) doesn't match the index correctly.
> 3) We explain how views work and also suggest our all_docs hack.
> 4) Then the user complains that their query is slow(due to all_docs or
> large result set), and again we try to either optimize the index or suggest
> using text indexes (the new open-sourced feature).
>
> A lot of users are turned off by the usability issues encountered in 1)
> and 2). I agree that we should make it as easy as possible for first time
> users, so I am okay with removing the need to create an index first.
> However, we need to somehow explicitly let the user know about all_docs so
> they don't abuse this capability. Also, like mongo, we could internally
> check if the current index is an all_docs index and throw a timeout/size
> error for a particular query?
>
>
> Thanks,
>
>
> Tony
>
> On Mon, Jan 4, 2016 at 11:49 AM, Sebastian Rothbucher <
> sebastianrothbucher@googlemail.com> wrote:
>
>> Hi Robert,
>>
>> I'm with you that the easier we can make it for s/o to get started the
>> better.
>> And I think falling back to a full table scan with a log written is a good
>> and easy way to go. I'd even set the log level to info or even warning to
>> make it clear that there's a problem with huge data sets. And hopefully,
>> people run some load test before going into production ;-)
>>
>> The only other idea I had (a button "use default index" in Fauxton that
>> modifies the selector) looks daft on second thought
>>
>> - I do like your idea though
>>
>> Best
>> Sebastian
>>
>>
>> On Mon, Jan 4, 2016 at 8:04 PM, Paul Davis <pa...@gmail.com>
>> wrote:
>>
>> > Hey all,
>> >
>> > I meant to reply to the ticket on pouchdb-find but got distracted by
>> > the holidays.
>> >
>> > I wanted to note that the original motivation for rejecting a selector
>> > that doesn't have an index was to avoid the specific situation where a
>> > user has a query that appears to run quite quickly in testing/dev but
>> > fails or results in timeouts in production due to a different data
>> > set. This was definitely a deviation from the MongoDB approach. The
>> > last I read their docs on this they mentioned in a couple places that
>> > while an index is not required there are limits on result set sizes
>> > and (I think?) query time. I made the choice that rather than fail
>> > eventually to fail quickly and hopefully be descriptive of why the
>> > query failed. For instance, there should be a note in the error
>> > response when no index is available that describes which fields could
>> > be indexed to satisfy the query.
>> >
>> > On the other hand, once we had users actually playing with this
>> > feature there were quite a few instances of, "I just want to try this
>> > query without waiting for an index to build." and I made the clever
>> > suggestion that just adding the {"$and": [Query, {"_id": {"$gt":
>> > null}}]} wrapper would cause a full table scan. That's obviously a
>> > hack and I was fine with that because it seemed like an obvious hack
>> > that would motivate users to create the appropriate index before
>> > moving to production.
>> >
>> > On the flip side it seems like for some people the hack is a hurdle
>> > into learning the query capabilities as well as adding to the overhead
>> > of learning CouchDB in general. And this particular feature was aimed
>> > directly at providing an easier on-ramp to CouchDB for people coming
>> > from other databases. Given what I've read here and elsewhere perhaps
>> > what might be easiest would be to add a feature along the lines of
>> > "developing": "true" to the _find request body that would enable the
>> > _all_docs fold. This would provide two benefits in that internally we
>> > could throw different errors in specific cases. For instances, some
>> > selectors fail because they can't run against a map/reduce index (ie,
>> > $or) and that won't change no matter what map/reduce indexes are
>> > added. If we just wrap the the _all_docs hack this changes the
>> > behavior which would probably surprise new users.
>> >
>> > On the other hand, indexes can be operationally quite costly and
>> > require planning to handle capacity so I would definitely avoid
>> > automatically creating them from the _find endpoint. Perhaps we could
>> > add a feature for the _index endpoint that accepts a selector and
>> > figures out the index to create. Which I think is along the lines of
>> > what Dale mentioned but with a slightly more on purpose interaction
>> > from the user.
>> >
>> > Paul
>> >
>> > On Mon, Jan 4, 2016 at 8:05 AM, Garren Smith <ga...@apache.org> wrote:
>> > > Hi Robert,
>> > >
>> > > This is cool. I think it links in with this
>> > https://issues.apache.org/jira/browse/COUCHDB-2928 <
>> > https://issues.apache.org/jira/browse/COUCHDB-2928> and this
>> > https://github.com/nolanlawson/pouchdb-find/issues/138 <
>> > https://github.com/nolanlawson/pouchdb-find/issues/138>
>> > >
>> > > Cheers
>> > > Garren
>> > >
>> > >> On 04 Jan 2016, at 2:33 PM, Dale Harvey <da...@arandomurl.com> wrote:
>> > >>
>> > >> I havent yet started looking into the implementation details, but when
>> > >> using pouchdb-find I have very much always expected that at some point
>> > we
>> > >> would analyse the queries and automatically produce an index for them.
>> > This
>> > >> seems like a great step in between.
>> > >>
>> > >> On 4 January 2016 at 13:27, Robert Kowalski <ro...@kowalski.gd> wrote:
>> > >>
>> > >>> Hi list,
>> > >>>
>> > >>> I hope you had awesome holidays!
>> > >>>
>> > >>> The whole holidays I thought about an idea I had and today I
>> > >>> implemented a prototype which still has some bugs and isn't complete
>> > >>> yet.
>> > >>>
>> > >>> I want to find out if there is general interest and if it would be
>> > >>> worth to spend more time.
>> > >>>
>> > >>> The problem I am trying to solve is that I usually have a hard time
>> > >>> explaining people how views work. Now we got Mango and I can just
>> say:
>> > >>> we use a syntax similar to MongoDB's query language _but you have to
>> > >>> create an index before you can use it_.
>> > >>>
>> > >>> At this point I usually look into sad, big eyes because no one
>> > >>> understands why they have to create an index first and I feel there
>> is
>> > >>> another entry barrier for newcomers. If trying anyway given they have
>> > >>> decided for CouchDB the user gets a error back: "no index available
>> > >>> for this selector".
>> > >>>
>> > >>> The idea of this patch is to just fallback on the "give me all docs
>> > >>> and i filter afterwards"-trick that people usually use (if they know
>> > >>> it) when they just want to test something, without creating an index
>> > >>> which can take time for creation and requires further knowledge.
>> > >>> Additionally the user is warned that they can create an index to make
>> > >>> the queries faster.
>> > >>>
>> > >>> What do you think? Is that something worth to work on further? The PR
>> > >>> is at https://github.com/apache/couchdb-mango/pull/27
>> > >>>
>> > >>> You can test it with basic queries on a database which does not have
>> > >>> indexes for the fields you want to query created yet.
>> > >>>
>> > >>>
>> > >>> Best,
>> > >>> Robert :)
>> > >>>
>> > >
>> >
>>
Re: [POC] Mango Catch All Selector
Posted by Tony Sun <to...@gmail.com>.
Hi all,
Hope everyone enjoyed the holidays!
This is the most common mango experience for new users:
1) Syntax issues to create an index.
2) Running into the "no index found" error because his or her query
(with and w/o sort) doesn't match the index correctly.
3) We explain how views work and also suggest our all_docs hack.
4) Then the user complains that their query is slow(due to all_docs or
large result set), and again we try to either optimize the index or suggest
using text indexes (the new open-sourced feature).
A lot of users are turned off by the usability issues encountered in 1)
and 2). I agree that we should make it as easy as possible for first time
users, so I am okay with removing the need to create an index first.
However, we need to somehow explicitly let the user know about all_docs so
they don't abuse this capability. Also, like mongo, we could internally
check if the current index is an all_docs index and throw a timeout/size
error for a particular query?
Thanks,
Tony
On Mon, Jan 4, 2016 at 11:49 AM, Sebastian Rothbucher <
sebastianrothbucher@googlemail.com> wrote:
> Hi Robert,
>
> I'm with you that the easier we can make it for s/o to get started the
> better.
> And I think falling back to a full table scan with a log written is a good
> and easy way to go. I'd even set the log level to info or even warning to
> make it clear that there's a problem with huge data sets. And hopefully,
> people run some load test before going into production ;-)
>
> The only other idea I had (a button "use default index" in Fauxton that
> modifies the selector) looks daft on second thought
>
> - I do like your idea though
>
> Best
> Sebastian
>
>
> On Mon, Jan 4, 2016 at 8:04 PM, Paul Davis <pa...@gmail.com>
> wrote:
>
> > Hey all,
> >
> > I meant to reply to the ticket on pouchdb-find but got distracted by
> > the holidays.
> >
> > I wanted to note that the original motivation for rejecting a selector
> > that doesn't have an index was to avoid the specific situation where a
> > user has a query that appears to run quite quickly in testing/dev but
> > fails or results in timeouts in production due to a different data
> > set. This was definitely a deviation from the MongoDB approach. The
> > last I read their docs on this they mentioned in a couple places that
> > while an index is not required there are limits on result set sizes
> > and (I think?) query time. I made the choice that rather than fail
> > eventually to fail quickly and hopefully be descriptive of why the
> > query failed. For instance, there should be a note in the error
> > response when no index is available that describes which fields could
> > be indexed to satisfy the query.
> >
> > On the other hand, once we had users actually playing with this
> > feature there were quite a few instances of, "I just want to try this
> > query without waiting for an index to build." and I made the clever
> > suggestion that just adding the {"$and": [Query, {"_id": {"$gt":
> > null}}]} wrapper would cause a full table scan. That's obviously a
> > hack and I was fine with that because it seemed like an obvious hack
> > that would motivate users to create the appropriate index before
> > moving to production.
> >
> > On the flip side it seems like for some people the hack is a hurdle
> > into learning the query capabilities as well as adding to the overhead
> > of learning CouchDB in general. And this particular feature was aimed
> > directly at providing an easier on-ramp to CouchDB for people coming
> > from other databases. Given what I've read here and elsewhere perhaps
> > what might be easiest would be to add a feature along the lines of
> > "developing": "true" to the _find request body that would enable the
> > _all_docs fold. This would provide two benefits in that internally we
> > could throw different errors in specific cases. For instances, some
> > selectors fail because they can't run against a map/reduce index (ie,
> > $or) and that won't change no matter what map/reduce indexes are
> > added. If we just wrap the the _all_docs hack this changes the
> > behavior which would probably surprise new users.
> >
> > On the other hand, indexes can be operationally quite costly and
> > require planning to handle capacity so I would definitely avoid
> > automatically creating them from the _find endpoint. Perhaps we could
> > add a feature for the _index endpoint that accepts a selector and
> > figures out the index to create. Which I think is along the lines of
> > what Dale mentioned but with a slightly more on purpose interaction
> > from the user.
> >
> > Paul
> >
> > On Mon, Jan 4, 2016 at 8:05 AM, Garren Smith <ga...@apache.org> wrote:
> > > Hi Robert,
> > >
> > > This is cool. I think it links in with this
> > https://issues.apache.org/jira/browse/COUCHDB-2928 <
> > https://issues.apache.org/jira/browse/COUCHDB-2928> and this
> > https://github.com/nolanlawson/pouchdb-find/issues/138 <
> > https://github.com/nolanlawson/pouchdb-find/issues/138>
> > >
> > > Cheers
> > > Garren
> > >
> > >> On 04 Jan 2016, at 2:33 PM, Dale Harvey <da...@arandomurl.com> wrote:
> > >>
> > >> I havent yet started looking into the implementation details, but when
> > >> using pouchdb-find I have very much always expected that at some point
> > we
> > >> would analyse the queries and automatically produce an index for them.
> > This
> > >> seems like a great step in between.
> > >>
> > >> On 4 January 2016 at 13:27, Robert Kowalski <ro...@kowalski.gd> wrote:
> > >>
> > >>> Hi list,
> > >>>
> > >>> I hope you had awesome holidays!
> > >>>
> > >>> The whole holidays I thought about an idea I had and today I
> > >>> implemented a prototype which still has some bugs and isn't complete
> > >>> yet.
> > >>>
> > >>> I want to find out if there is general interest and if it would be
> > >>> worth to spend more time.
> > >>>
> > >>> The problem I am trying to solve is that I usually have a hard time
> > >>> explaining people how views work. Now we got Mango and I can just
> say:
> > >>> we use a syntax similar to MongoDB's query language _but you have to
> > >>> create an index before you can use it_.
> > >>>
> > >>> At this point I usually look into sad, big eyes because no one
> > >>> understands why they have to create an index first and I feel there
> is
> > >>> another entry barrier for newcomers. If trying anyway given they have
> > >>> decided for CouchDB the user gets a error back: "no index available
> > >>> for this selector".
> > >>>
> > >>> The idea of this patch is to just fallback on the "give me all docs
> > >>> and i filter afterwards"-trick that people usually use (if they know
> > >>> it) when they just want to test something, without creating an index
> > >>> which can take time for creation and requires further knowledge.
> > >>> Additionally the user is warned that they can create an index to make
> > >>> the queries faster.
> > >>>
> > >>> What do you think? Is that something worth to work on further? The PR
> > >>> is at https://github.com/apache/couchdb-mango/pull/27
> > >>>
> > >>> You can test it with basic queries on a database which does not have
> > >>> indexes for the fields you want to query created yet.
> > >>>
> > >>>
> > >>> Best,
> > >>> Robert :)
> > >>>
> > >
> >
>
Re: [POC] Mango Catch All Selector
Posted by Sebastian Rothbucher <se...@googlemail.com>.
Hi Robert,
I'm with you that the easier we can make it for s/o to get started the
better.
And I think falling back to a full table scan with a log written is a good
and easy way to go. I'd even set the log level to info or even warning to
make it clear that there's a problem with huge data sets. And hopefully,
people run some load test before going into production ;-)
The only other idea I had (a button "use default index" in Fauxton that
modifies the selector) looks daft on second thought
- I do like your idea though
Best
Sebastian
On Mon, Jan 4, 2016 at 8:04 PM, Paul Davis <pa...@gmail.com>
wrote:
> Hey all,
>
> I meant to reply to the ticket on pouchdb-find but got distracted by
> the holidays.
>
> I wanted to note that the original motivation for rejecting a selector
> that doesn't have an index was to avoid the specific situation where a
> user has a query that appears to run quite quickly in testing/dev but
> fails or results in timeouts in production due to a different data
> set. This was definitely a deviation from the MongoDB approach. The
> last I read their docs on this they mentioned in a couple places that
> while an index is not required there are limits on result set sizes
> and (I think?) query time. I made the choice that rather than fail
> eventually to fail quickly and hopefully be descriptive of why the
> query failed. For instance, there should be a note in the error
> response when no index is available that describes which fields could
> be indexed to satisfy the query.
>
> On the other hand, once we had users actually playing with this
> feature there were quite a few instances of, "I just want to try this
> query without waiting for an index to build." and I made the clever
> suggestion that just adding the {"$and": [Query, {"_id": {"$gt":
> null}}]} wrapper would cause a full table scan. That's obviously a
> hack and I was fine with that because it seemed like an obvious hack
> that would motivate users to create the appropriate index before
> moving to production.
>
> On the flip side it seems like for some people the hack is a hurdle
> into learning the query capabilities as well as adding to the overhead
> of learning CouchDB in general. And this particular feature was aimed
> directly at providing an easier on-ramp to CouchDB for people coming
> from other databases. Given what I've read here and elsewhere perhaps
> what might be easiest would be to add a feature along the lines of
> "developing": "true" to the _find request body that would enable the
> _all_docs fold. This would provide two benefits in that internally we
> could throw different errors in specific cases. For instances, some
> selectors fail because they can't run against a map/reduce index (ie,
> $or) and that won't change no matter what map/reduce indexes are
> added. If we just wrap the the _all_docs hack this changes the
> behavior which would probably surprise new users.
>
> On the other hand, indexes can be operationally quite costly and
> require planning to handle capacity so I would definitely avoid
> automatically creating them from the _find endpoint. Perhaps we could
> add a feature for the _index endpoint that accepts a selector and
> figures out the index to create. Which I think is along the lines of
> what Dale mentioned but with a slightly more on purpose interaction
> from the user.
>
> Paul
>
> On Mon, Jan 4, 2016 at 8:05 AM, Garren Smith <ga...@apache.org> wrote:
> > Hi Robert,
> >
> > This is cool. I think it links in with this
> https://issues.apache.org/jira/browse/COUCHDB-2928 <
> https://issues.apache.org/jira/browse/COUCHDB-2928> and this
> https://github.com/nolanlawson/pouchdb-find/issues/138 <
> https://github.com/nolanlawson/pouchdb-find/issues/138>
> >
> > Cheers
> > Garren
> >
> >> On 04 Jan 2016, at 2:33 PM, Dale Harvey <da...@arandomurl.com> wrote:
> >>
> >> I havent yet started looking into the implementation details, but when
> >> using pouchdb-find I have very much always expected that at some point
> we
> >> would analyse the queries and automatically produce an index for them.
> This
> >> seems like a great step in between.
> >>
> >> On 4 January 2016 at 13:27, Robert Kowalski <ro...@kowalski.gd> wrote:
> >>
> >>> Hi list,
> >>>
> >>> I hope you had awesome holidays!
> >>>
> >>> The whole holidays I thought about an idea I had and today I
> >>> implemented a prototype which still has some bugs and isn't complete
> >>> yet.
> >>>
> >>> I want to find out if there is general interest and if it would be
> >>> worth to spend more time.
> >>>
> >>> The problem I am trying to solve is that I usually have a hard time
> >>> explaining people how views work. Now we got Mango and I can just say:
> >>> we use a syntax similar to MongoDB's query language _but you have to
> >>> create an index before you can use it_.
> >>>
> >>> At this point I usually look into sad, big eyes because no one
> >>> understands why they have to create an index first and I feel there is
> >>> another entry barrier for newcomers. If trying anyway given they have
> >>> decided for CouchDB the user gets a error back: "no index available
> >>> for this selector".
> >>>
> >>> The idea of this patch is to just fallback on the "give me all docs
> >>> and i filter afterwards"-trick that people usually use (if they know
> >>> it) when they just want to test something, without creating an index
> >>> which can take time for creation and requires further knowledge.
> >>> Additionally the user is warned that they can create an index to make
> >>> the queries faster.
> >>>
> >>> What do you think? Is that something worth to work on further? The PR
> >>> is at https://github.com/apache/couchdb-mango/pull/27
> >>>
> >>> You can test it with basic queries on a database which does not have
> >>> indexes for the fields you want to query created yet.
> >>>
> >>>
> >>> Best,
> >>> Robert :)
> >>>
> >
>
Re: [POC] Mango Catch All Selector
Posted by Paul Davis <pa...@gmail.com>.
Hey all,
I meant to reply to the ticket on pouchdb-find but got distracted by
the holidays.
I wanted to note that the original motivation for rejecting a selector
that doesn't have an index was to avoid the specific situation where a
user has a query that appears to run quite quickly in testing/dev but
fails or results in timeouts in production due to a different data
set. This was definitely a deviation from the MongoDB approach. The
last I read their docs on this they mentioned in a couple places that
while an index is not required there are limits on result set sizes
and (I think?) query time. I made the choice that rather than fail
eventually to fail quickly and hopefully be descriptive of why the
query failed. For instance, there should be a note in the error
response when no index is available that describes which fields could
be indexed to satisfy the query.
On the other hand, once we had users actually playing with this
feature there were quite a few instances of, "I just want to try this
query without waiting for an index to build." and I made the clever
suggestion that just adding the {"$and": [Query, {"_id": {"$gt":
null}}]} wrapper would cause a full table scan. That's obviously a
hack and I was fine with that because it seemed like an obvious hack
that would motivate users to create the appropriate index before
moving to production.
On the flip side it seems like for some people the hack is a hurdle
into learning the query capabilities as well as adding to the overhead
of learning CouchDB in general. And this particular feature was aimed
directly at providing an easier on-ramp to CouchDB for people coming
from other databases. Given what I've read here and elsewhere perhaps
what might be easiest would be to add a feature along the lines of
"developing": "true" to the _find request body that would enable the
_all_docs fold. This would provide two benefits in that internally we
could throw different errors in specific cases. For instances, some
selectors fail because they can't run against a map/reduce index (ie,
$or) and that won't change no matter what map/reduce indexes are
added. If we just wrap the the _all_docs hack this changes the
behavior which would probably surprise new users.
On the other hand, indexes can be operationally quite costly and
require planning to handle capacity so I would definitely avoid
automatically creating them from the _find endpoint. Perhaps we could
add a feature for the _index endpoint that accepts a selector and
figures out the index to create. Which I think is along the lines of
what Dale mentioned but with a slightly more on purpose interaction
from the user.
Paul
On Mon, Jan 4, 2016 at 8:05 AM, Garren Smith <ga...@apache.org> wrote:
> Hi Robert,
>
> This is cool. I think it links in with this https://issues.apache.org/jira/browse/COUCHDB-2928 <https://issues.apache.org/jira/browse/COUCHDB-2928> and this https://github.com/nolanlawson/pouchdb-find/issues/138 <https://github.com/nolanlawson/pouchdb-find/issues/138>
>
> Cheers
> Garren
>
>> On 04 Jan 2016, at 2:33 PM, Dale Harvey <da...@arandomurl.com> wrote:
>>
>> I havent yet started looking into the implementation details, but when
>> using pouchdb-find I have very much always expected that at some point we
>> would analyse the queries and automatically produce an index for them. This
>> seems like a great step in between.
>>
>> On 4 January 2016 at 13:27, Robert Kowalski <ro...@kowalski.gd> wrote:
>>
>>> Hi list,
>>>
>>> I hope you had awesome holidays!
>>>
>>> The whole holidays I thought about an idea I had and today I
>>> implemented a prototype which still has some bugs and isn't complete
>>> yet.
>>>
>>> I want to find out if there is general interest and if it would be
>>> worth to spend more time.
>>>
>>> The problem I am trying to solve is that I usually have a hard time
>>> explaining people how views work. Now we got Mango and I can just say:
>>> we use a syntax similar to MongoDB's query language _but you have to
>>> create an index before you can use it_.
>>>
>>> At this point I usually look into sad, big eyes because no one
>>> understands why they have to create an index first and I feel there is
>>> another entry barrier for newcomers. If trying anyway given they have
>>> decided for CouchDB the user gets a error back: "no index available
>>> for this selector".
>>>
>>> The idea of this patch is to just fallback on the "give me all docs
>>> and i filter afterwards"-trick that people usually use (if they know
>>> it) when they just want to test something, without creating an index
>>> which can take time for creation and requires further knowledge.
>>> Additionally the user is warned that they can create an index to make
>>> the queries faster.
>>>
>>> What do you think? Is that something worth to work on further? The PR
>>> is at https://github.com/apache/couchdb-mango/pull/27
>>>
>>> You can test it with basic queries on a database which does not have
>>> indexes for the fields you want to query created yet.
>>>
>>>
>>> Best,
>>> Robert :)
>>>
>
Re: [POC] Mango Catch All Selector
Posted by Garren Smith <ga...@apache.org>.
Hi Robert,
This is cool. I think it links in with this https://issues.apache.org/jira/browse/COUCHDB-2928 <https://issues.apache.org/jira/browse/COUCHDB-2928> and this https://github.com/nolanlawson/pouchdb-find/issues/138 <https://github.com/nolanlawson/pouchdb-find/issues/138>
Cheers
Garren
> On 04 Jan 2016, at 2:33 PM, Dale Harvey <da...@arandomurl.com> wrote:
>
> I havent yet started looking into the implementation details, but when
> using pouchdb-find I have very much always expected that at some point we
> would analyse the queries and automatically produce an index for them. This
> seems like a great step in between.
>
> On 4 January 2016 at 13:27, Robert Kowalski <ro...@kowalski.gd> wrote:
>
>> Hi list,
>>
>> I hope you had awesome holidays!
>>
>> The whole holidays I thought about an idea I had and today I
>> implemented a prototype which still has some bugs and isn't complete
>> yet.
>>
>> I want to find out if there is general interest and if it would be
>> worth to spend more time.
>>
>> The problem I am trying to solve is that I usually have a hard time
>> explaining people how views work. Now we got Mango and I can just say:
>> we use a syntax similar to MongoDB's query language _but you have to
>> create an index before you can use it_.
>>
>> At this point I usually look into sad, big eyes because no one
>> understands why they have to create an index first and I feel there is
>> another entry barrier for newcomers. If trying anyway given they have
>> decided for CouchDB the user gets a error back: "no index available
>> for this selector".
>>
>> The idea of this patch is to just fallback on the "give me all docs
>> and i filter afterwards"-trick that people usually use (if they know
>> it) when they just want to test something, without creating an index
>> which can take time for creation and requires further knowledge.
>> Additionally the user is warned that they can create an index to make
>> the queries faster.
>>
>> What do you think? Is that something worth to work on further? The PR
>> is at https://github.com/apache/couchdb-mango/pull/27
>>
>> You can test it with basic queries on a database which does not have
>> indexes for the fields you want to query created yet.
>>
>>
>> Best,
>> Robert :)
>>
Re: [POC] Mango Catch All Selector
Posted by Dale Harvey <da...@arandomurl.com>.
I havent yet started looking into the implementation details, but when
using pouchdb-find I have very much always expected that at some point we
would analyse the queries and automatically produce an index for them. This
seems like a great step in between.
On 4 January 2016 at 13:27, Robert Kowalski <ro...@kowalski.gd> wrote:
> Hi list,
>
> I hope you had awesome holidays!
>
> The whole holidays I thought about an idea I had and today I
> implemented a prototype which still has some bugs and isn't complete
> yet.
>
> I want to find out if there is general interest and if it would be
> worth to spend more time.
>
> The problem I am trying to solve is that I usually have a hard time
> explaining people how views work. Now we got Mango and I can just say:
> we use a syntax similar to MongoDB's query language _but you have to
> create an index before you can use it_.
>
> At this point I usually look into sad, big eyes because no one
> understands why they have to create an index first and I feel there is
> another entry barrier for newcomers. If trying anyway given they have
> decided for CouchDB the user gets a error back: "no index available
> for this selector".
>
> The idea of this patch is to just fallback on the "give me all docs
> and i filter afterwards"-trick that people usually use (if they know
> it) when they just want to test something, without creating an index
> which can take time for creation and requires further knowledge.
> Additionally the user is warned that they can create an index to make
> the queries faster.
>
> What do you think? Is that something worth to work on further? The PR
> is at https://github.com/apache/couchdb-mango/pull/27
>
> You can test it with basic queries on a database which does not have
> indexes for the fields you want to query created yet.
>
>
> Best,
> Robert :)
>