You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Henrik Skupin <hs...@gmail.com> on 2010/09/12 09:35:03 UTC
Query parameters in rewrites.json not handled as default values
Hi,
During this week while being at Couchcamp I have already talked to Chris and
we decided to follow-up on the topic in the mailing list.
With the latest version of CouchDB the URL parameters don't seem be 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 default values are always used. Once
the limit entry gets removed from the rewrites.json file, the URL parameter
is used and 10 rows are displayed.
IMO the values specified in rewrites.json should really be default ones and
should not override user defined values.
Henrik
Re: Query parameters in rewrites.json not handled as default values
Posted by Henrik Skupin <hs...@gmail.com>.
On Sun, Sep 12, 2010 at 1:15 PM, Benoit Chesneau <bc...@gmail.com>wrote:
>
> ok , go for it then. I will try provides the code tomorrow.
>
>
Has been created:
https://issues.apache.org/jira/browse/COUCHDB-886
Thanks,
--
Henrik Skupin
QA Engineer
Mozilla Corporation
Re: Query parameters in rewrites.json not handled as default values
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Sep 12, 2010 at 7:16 PM, J Chris Anderson <jc...@apache.org> wrote:
>
> On Sep 12, 2010, at 9:00 AM, Benoit Chesneau wrote:
>
>> On Sun, Sep 12, 2010 at 5:43 PM, Henrik Skupin <hs...@gmail.com> wrote:
>>> On Sun, Sep 12, 2010 at 4:08 AM, Benoit Chesneau <bc...@gmail.com>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
Re: Query parameters in rewrites.json not handled as default values
Posted by J Chris Anderson <jc...@apache.org>.
On Sep 12, 2010, at 9:00 AM, Benoit Chesneau wrote:
> On Sun, Sep 12, 2010 at 5:43 PM, Henrik Skupin <hs...@gmail.com> wrote:
>> On Sun, Sep 12, 2010 at 4:08 AM, Benoit Chesneau <bc...@gmail.com>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
Re: Query parameters in rewrites.json not handled as default values
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Sep 12, 2010 at 5:43 PM, Henrik Skupin <hs...@gmail.com> wrote:
> On Sun, Sep 12, 2010 at 4:08 AM, Benoit Chesneau <bc...@gmail.com>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.
- benoit
Re: Query parameters in rewrites.json not handled as default values
Posted by Henrik Skupin <hs...@gmail.com>.
On Sun, Sep 12, 2010 at 4:08 AM, Benoit Chesneau <bc...@gmail.com>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
Re: Query parameters in rewrites.json not handled as default values
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Sep 12, 2010 at 11:20 AM, J Chris Anderson <jc...@apache.org> wrote:
>
> On Sep 12, 2010, at 12:35 AM, Henrik Skupin wrote:
>
>> Hi,
>>
>> During this week while being at Couchcamp I have already talked to Chris and
>> we decided to follow-up on the topic in the mailing list.
>>
>
> I'm seeing this behavior also, and agree it should be fixed. Do you mind filing a bug report for it?
>
> http://issues.apache.org/jira/browse/COUCHDB
>
> At CouchCamp I said I thought this was working, but it's not working in the places I've checked, so I think it needs fixing.
>
> Chris
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.
- benoit
Re: Query parameters in rewrites.json not handled as default values
Posted by J Chris Anderson <jc...@apache.org>.
On Sep 12, 2010, at 12:35 AM, Henrik Skupin wrote:
> Hi,
>
> During this week while being at Couchcamp I have already talked to Chris and
> we decided to follow-up on the topic in the mailing list.
>
I'm seeing this behavior also, and agree it should be fixed. Do you mind filing a bug report for it?
http://issues.apache.org/jira/browse/COUCHDB
At CouchCamp I said I thought this was working, but it's not working in the places I've checked, so I think it needs fixing.
Chris
> With the latest version of CouchDB the URL parameters don't seem be 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 default values are always used. Once
> the limit entry gets removed from the rewrites.json file, the URL parameter
> is used and 10 rows are displayed.
>
> IMO the values specified in rewrites.json should really be default ones and
> should not override user defined values.
>
> Henrik