You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jarrod Roberson <ja...@vertigrated.com> on 2010/04/29 07:32:35 UTC
adding the ability to do a POST to _changes
I have been able to add the ability to do a POST to _changes in
couch_httpd_db.erl but I I just get a raw body element with the string of
JSON.
How do I get it to parse the json in the body like a keys POST to a _view?
What I am trying to do is add the ability of a _filter to have a list of
keys and only send me the ids that are in the list of keys that I specify in
the POST to _changes.
--
Jarrod Roberson
Re: adding the ability to do a POST to _changes
Posted by Jarrod Roberson <ja...@vertigrated.com>.
On Thu, Apr 29, 2010 at 1:05 PM, Ning Tan <ni...@gmail.com> wrote:
> Same here. Chris asked me to submit a futon test case. I opened the
> Jira issue and attached a test case. Please vote for the ticket! :-)
>
I already did, I think the use case for passing in a list of ids is very
important
--
Jarrod Roberson
Re: adding the ability to do a POST to _changes
Posted by Ning Tan <ni...@gmail.com>.
Same here. Chris asked me to submit a futon test case. I opened the
Jira issue and attached a test case. Please vote for the ticket! :-)
On Thu, Apr 29, 2010 at 12:21 PM, Jarrod Roberson
<ja...@vertigrated.com> wrote:
> On Thu, Apr 29, 2010 at 12:20 PM, Jarrod Roberson <ja...@vertigrated.com>wrote:
>
>> my debug.js filter that just logged the contents of the request is working.
>> but anything that actually tries to return true/false just hangs with a
>> partially serialzied results
>>
>>
> function(doc, req)
> {
> var ids = JSON.parse(req.body);
> log(toJSON(ids));
> var result = false;
> for (var i = 0; i < ids.length; i++)
> {
> log(ids[i]);
> if (ids[i] == doc._id) { result = true; break; }
> }
> return result;
> }
>
>
>> curl -X POST http://localhost:5984/mydb/_changes?filter=transfer/by_ids -d
>> '
>> ["123","job_id:1234567890"]'
>> {"results":[
>>
>
>
>
> --
> Jarrod Roberson
> 678.551.2852
>
Re: adding the ability to do a POST to _changes
Posted by Jarrod Roberson <ja...@vertigrated.com>.
On Thu, Apr 29, 2010 at 12:20 PM, Jarrod Roberson <ja...@vertigrated.com>wrote:
> my debug.js filter that just logged the contents of the request is working.
> but anything that actually tries to return true/false just hangs with a
> partially serialzied results
>
>
function(doc, req)
{
var ids = JSON.parse(req.body);
log(toJSON(ids));
var result = false;
for (var i = 0; i < ids.length; i++)
{
log(ids[i]);
if (ids[i] == doc._id) { result = true; break; }
}
return result;
}
> curl -X POST http://localhost:5984/mydb/_changes?filter=transfer/by_ids -d
> '
> ["123","job_id:1234567890"]'
> {"results":[
>
--
Jarrod Roberson
678.551.2852
Re: adding the ability to do a POST to _changes
Posted by Jarrod Roberson <ja...@vertigrated.com>.
my debug.js filter that just logged the contents of the request is working.
but anything that actually tries to return true/false just hangs with a
partially serialzied results
curl -X POST http://localhost:5984/mydb/_changes?filter=transfer/by_ids -d '
["123","job_id:1234567890"]'
{"results":[
--
Jarrod Roberson
678.551.2852
Re: adding the ability to do a POST to _changes
Posted by Ning Tan <ni...@gmail.com>.
Were you able to let this new test I wrote pass in Futon? I
practically did the same thing to enable POSTing to _changes filters,
but the request hangs for me. See here:
https://issues.apache.org/jira/browse/COUCHDB-735
On Thu, Apr 29, 2010 at 2:14 AM, J Chris Anderson <jc...@gmail.com> wrote:
>
> On Apr 28, 2010, at 11:07 PM, Jarrod Roberson wrote:
>
>> On Thu, Apr 29, 2010 at 1:54 AM, J Chris Anderson <jc...@gmail.com> wrote:
>>
>>>
>>>
>>> Your JavaScript function should be able to accept the POST body and use it
>>> to decide whether to return true or false. So you can parse the JSON in your
>>> _filter fun and return true or false based on a docid match.
>>>
>>>
>> That is exactly what I came up with, but it seems a little expensive to
>> parse that JSON over and over for every document that gets changed I figured
>> it would be more efficient to do it in the Erlang layer once and be done
>> with it.
>>
>
> There are a million optimizations it'd be nice to have. As a project we are focussed on getting the programming model solid and flexible enough. After 1.0 we'll focus on optimizations.
>
> There is a patch in 0.11 to allow for replication by docid. There should be a test case for it, and a closed Jira issue. I haven't used it yet but I'm pretty sure I remember it being applied.
>
> Chris
>
>
>> --
>> Jarrod Roberson
>
>
Re: adding the ability to do a POST to _changes
Posted by J Chris Anderson <jc...@gmail.com>.
On Apr 28, 2010, at 11:07 PM, Jarrod Roberson wrote:
> On Thu, Apr 29, 2010 at 1:54 AM, J Chris Anderson <jc...@gmail.com> wrote:
>
>>
>>
>> Your JavaScript function should be able to accept the POST body and use it
>> to decide whether to return true or false. So you can parse the JSON in your
>> _filter fun and return true or false based on a docid match.
>>
>>
> That is exactly what I came up with, but it seems a little expensive to
> parse that JSON over and over for every document that gets changed I figured
> it would be more efficient to do it in the Erlang layer once and be done
> with it.
>
There are a million optimizations it'd be nice to have. As a project we are focussed on getting the programming model solid and flexible enough. After 1.0 we'll focus on optimizations.
There is a patch in 0.11 to allow for replication by docid. There should be a test case for it, and a closed Jira issue. I haven't used it yet but I'm pretty sure I remember it being applied.
Chris
> --
> Jarrod Roberson
Re: adding the ability to do a POST to _changes
Posted by Jarrod Roberson <ja...@vertigrated.com>.
On Thu, Apr 29, 2010 at 1:54 AM, J Chris Anderson <jc...@gmail.com> wrote:
>
>
> Your JavaScript function should be able to accept the POST body and use it
> to decide whether to return true or false. So you can parse the JSON in your
> _filter fun and return true or false based on a docid match.
>
>
That is exactly what I came up with, but it seems a little expensive to
parse that JSON over and over for every document that gets changed I figured
it would be more efficient to do it in the Erlang layer once and be done
with it.
--
Jarrod Roberson
Re: adding the ability to do a POST to _changes
Posted by J Chris Anderson <jc...@gmail.com>.
On Apr 28, 2010, at 10:32 PM, Jarrod Roberson wrote:
> I have been able to add the ability to do a POST to _changes in
> couch_httpd_db.erl but I I just get a raw body element with the string of
> JSON.
> How do I get it to parse the json in the body like a keys POST to a _view?
> What I am trying to do is add the ability of a _filter to have a list of
> keys and only send me the ids that are in the list of keys that I specify in
> the POST to _changes.
>
Your JavaScript function should be able to accept the POST body and use it to decide whether to return true or false. So you can parse the JSON in your _filter fun and return true or false based on a docid match.
I hope that helps.
Thanks for hacking that patch. I owe you some patch application wuffie b/c I know you have the _list patch for couch.js too.
Thanks for the hard work!
Cheers,
Chris
> --
> Jarrod Roberson