CouchDB
  1. CouchDB
  2. COUCHDB-886

Add option to set query options, defined in rewrites.json, as default

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Database Core
    • Labels:
      None
    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      With the latest version of CouchDB the URL parameters are not taken into account when the rewrites.json file specifies the same ones for the appropriate entry. See the following example:

      {
      "from" : "/general/reports",
      "to" : "_list/general_reports/general_reportsByDate",
      "query" :

      { "descending" : true, "limit" : 51 }

      }

      default values: http://mozmill.hskupin.info/general/reports
      custom values: http://mozmill.hskupin.info/general/reports?limit=10

      Whether which URL you are loading, the values from rewrites.json are always used. Once the limit entry gets removed from that file, the URL parameter is used and 10 rows are displayed.

      As proposed by Benoit query entries should be explicitly allowed to have a default value. Otherwise the value from rewrites.json has the priority.

      "query": {
      "key":

      { "value": ":var", "default": 1}

      }

      Can true be used instead of a number? It could be confusing this way, especially when the value is also a number.

        Activity

        Hide
        Chris Anderson added a comment -

        I believe came to the conclusion that the feature would look like:

        {
        "from" : "/general/reports",
        "to" : "_list/general_reports/general_reportsByDate",
        "query" :

        { "descending" : true }

        ,
        "default" :

        { "limit: 51 }

        }

        where the "query" definition will continue to be mandatory, but the defaults will be overridable by the client.

        I'm not sure I like this... what if instead, the "query" parameter were to revert to the old behavior (where the client can override it, and for the case where application designers want to force a particular query, we could have "enforced-query". with that notion, the previous example would look like this:

        {
        "from" : "/general/reports",
        "to" : "_list/general_reports/general_reportsByDate",
        "query" :

        { "limit: 51 }

        ,
        "enforced-query" :

        { "descending" : true }

        }

        The reason to have 2 members is to maintain backwards compatibility with existing rewrite rules. I also think it is a bit clearer than the alternative.

        Show
        Chris Anderson added a comment - I believe came to the conclusion that the feature would look like: { "from" : "/general/reports", "to" : "_list/general_reports/general_reportsByDate", "query" : { "descending" : true } , "default" : { "limit: 51 } } where the "query" definition will continue to be mandatory, but the defaults will be overridable by the client. I'm not sure I like this... what if instead, the "query" parameter were to revert to the old behavior (where the client can override it, and for the case where application designers want to force a particular query, we could have "enforced-query". with that notion, the previous example would look like this: { "from" : "/general/reports", "to" : "_list/general_reports/general_reportsByDate", "query" : { "limit: 51 } , "enforced-query" : { "descending" : true } } The reason to have 2 members is to maintain backwards compatibility with existing rewrite rules. I also think it is a bit clearer than the alternative.
        Hide
        Benoit Chesneau added a comment -

        the problem with all of this is to allows the users to override query parameters.

        Ex if I have this rule:

        {
        "from": "/city/paris",
        "to": "_list/test",
        "query":

        { "startkey": "paris", 'endkey": ":paris\0" }

        If we make query overridable, that mean that someone passing starkey=&endkey= will override the path rule. Here we are in a simple case so it doesn't really matter, but it could be worth. If we have default on the other hand, for example with a limit parameter :

        {
        "from": "/city/paris",
        "to": "_list/test",
        "query":

        { "startkey": "paris", "endkey": ":paris\0", "limit": ":llimit" }

        ,
        "default":

        { "limit": 10 }

        }

        Then if we do /city/paris, the default limit will be use while if we do /city/paris?limit=50, limit query parameter will be used.

        Imo, "default": {} is really the tight way to handle such problem.

        Show
        Benoit Chesneau added a comment - the problem with all of this is to allows the users to override query parameters. Ex if I have this rule: { "from": "/city/paris", "to": "_list/test", "query": { "startkey": "paris", 'endkey": ":paris\0" } If we make query overridable, that mean that someone passing starkey=&endkey= will override the path rule. Here we are in a simple case so it doesn't really matter, but it could be worth. If we have default on the other hand, for example with a limit parameter : { "from": "/city/paris", "to": "_list/test", "query": { "startkey": "paris", "endkey": ":paris\0", "limit": ":llimit" } , "default": { "limit": 10 } } Then if we do /city/paris, the default limit will be use while if we do /city/paris?limit=50, limit query parameter will be used. Imo, "default": {} is really the tight way to handle such problem.
        Hide
        Ryan Hill added a comment -

        Why not split the difference?

        Let 'query' be strictly immutable, and let URL parameters override 'default' values.
        Values in 'query' would also override 'default' values.

        Seems like a relaxed approach to me.

        Show
        Ryan Hill added a comment - Why not split the difference? Let 'query' be strictly immutable, and let URL parameters override 'default' values. Values in 'query' would also override 'default' values. Seems like a relaxed approach to me.
        Hide
        Chris Anderson added a comment -

        Ryan's proposal is what I was proposing:

        the required-query stuff overrides any defaults (if both specify a param)

        I'm not sure about naming, I just want it to be clear to users which is which...

        so "defaults" and "query" (maybe 'defaults' is better than 'default' as 'default' is a javascript keyword, which can be a surprise if you use it unquoted)

        or

        "query" and "enforced-query"

        or something else.

        The only requirement being that one of them is named "query" for the sake of backwards compatibility.

        Show
        Chris Anderson added a comment - Ryan's proposal is what I was proposing: the required-query stuff overrides any defaults (if both specify a param) I'm not sure about naming, I just want it to be clear to users which is which... so "defaults" and "query" (maybe 'defaults' is better than 'default' as 'default' is a javascript keyword, which can be a surprise if you use it unquoted) or "query" and "enforced-query" or something else. The only requirement being that one of them is named "query" for the sake of backwards compatibility.
        Hide
        Benoit Chesneau added a comment -

        so just t be clear process is :

        query >> url query params >> query-overrides (or defaults whatever) -> final query params ?

        • benoit
        Show
        Benoit Chesneau added a comment - so just t be clear process is : query >> url query params >> query-overrides (or defaults whatever) -> final query params ? benoit
        Hide
        Chris Anderson added a comment -

        yes/

        query >> request params >> defaults --> used requests

        Show
        Chris Anderson added a comment - yes/ query >> request params >> defaults --> used requests
        Hide
        Benoit Chesneau added a comment -

        ok. will provide the patch in the week.

        Show
        Benoit Chesneau added a comment - ok. will provide the patch in the week.
        Hide
        Adam Kocoloski added a comment -

        Not a Bug.

        Show
        Adam Kocoloski added a comment - Not a Bug.
        Hide
        Robin Millette added a comment -

        Somewhat related to COUCHDB-1188 (View query option defaults)

        Show
        Robin Millette added a comment - Somewhat related to COUCHDB-1188 (View query option defaults)

          People

          • Assignee:
            Benoit Chesneau
            Reporter:
            Henrik Skupin
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development