On Sun, Sep 12, 2010 at 7:16 PM, J Chris Anderson <[email protected]> wrote: > > 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 > >
ok , go for it then. I will try provides the code tomorrow. - benoit
