On Sep 12, 2010, at 9:00 AM, Benoit Chesneau wrote: > On Sun, Sep 12, 2010 at 5:43 PM, Henrik Skupin <[email protected]> wrote: >> On Sun, Sep 12, 2010 at 4:08 AM, Benoit Chesneau <[email protected]>wrote: >> >>> >>> Well it will be a regression then. It has worked like this, and after >>> your request, we discussed about changed it . The point is that you >>> didn't want that someone can override values defined in the ddoc and I >>> think you had a case for this. >>> >>> I'm not sure what is the right way to handle it right now and we >>> should consider all the usecases before changing anything. >>> >> >> I'm happy to file a bug report but I agree. If that behavior has been >> changed on purpose, it would be good to know the reasons. Do you have the >> bug # or the changeset, which has been changed this behavior, so we have a >> reference point? >> >> -- >> Henrik Skupin >> QA Engineer >> Mozilla Corporation >> > > I thas been discussed on pre-release cycle unfortunatly :/ But If I > remember the question about using query as a default or a way to fix > variable was around the question : "How do we make sure the > startkey/endkey for this path aren't rewritten?". Which is I think a > good question. From time to time you want to make sure that the path > /key is always the patch routing the key for this list. or /about go > to a doc with some id. > > Instead of using query for the defaults, I would suggest to introduce > a `default` member to the rule or maybe a way to set as a default > value in the query like : > > "query": { > "key": { "default": 1, "value": ":var"} > } > > I've a preference for a `default`member though, it eases the code imo. >
yes I agree default is easier (and also backwards compatible to just leave the existing query definition alone). Chris > - benoit
