You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2010/10/13 17:24:34 UTC
filter changes for some docids
Hi all,
For a project I have to know each time a design doc change and for now
I have to create a filter function for each databases created to do
that. I think getting changes on specific docids is a common behavior
(see replication for example) so I thought to add the possibility to
filters changes on docids if a list of documents is passed in the
request.
ex:
POST /db/_changes
{"docids": ["id1", ..]}
Here is the patch that allows that feature :
http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
What do you think about it ?
- benoit
Re: filter changes for some docids
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Oct 18, 2010 at 12:21 PM, Filipe David Manana
<fd...@apache.org> wrote:
> On Sun, Oct 17, 2010 at 6:20 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> Hi Benoit, all,
>>
>> I'm not too happy with how this turned out.
>>
>> There's multiple things this patch is trying to solve and by thinking about them separately, I think we can come up with a cleaner, more future-proof design. I'd like to avoid special casing for situations we think are common but turn out not to be.
>>
>> 1. Built-in filters. Much like built in reduce functions, the _doc_Ids filter could be built-in. This would allow us to add more built-in filter functions in the future when we discover patterns there.
>
> Exactly. Like we have the "special " reduce functions "_sum" and
> "_count" for views for e.g.
>
>>
>> 2. POST-ing arguments to _changes. This is needed because there are practical limits on the URL length so we can't send a large number of URL parameters. This is the same reason we have POST to views.
>>
>> Together, 1. & 2. can solve what you need and they also help us keep the improvements Filipe said could be roll into the replicator while at the same time we don't code ourselves into a corner for future additions.
>
> Instead of a doc_ids parameter to changes, I was thinking that to
> achieve the same goal, we could still use the "filter" parameter that
> would have a different value for very common cases, starting with an
> "_" just like for the special reduce cases. (the list of doc IDs would
> then be a regular parameter to the builtin Erlang filter function)
>
having a parameter for that isn't really RESTful. We already have the
POST meaning. Why do we need another param in url ? I've tjinking to
the filter args before code that and rejected for abive reason.
- benoit
Re: filter changes for some docids
Posted by Filipe David Manana <fd...@apache.org>.
On Sun, Oct 17, 2010 at 6:20 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Hi Benoit, all,
>
> I'm not too happy with how this turned out.
>
> There's multiple things this patch is trying to solve and by thinking about them separately, I think we can come up with a cleaner, more future-proof design. I'd like to avoid special casing for situations we think are common but turn out not to be.
>
> 1. Built-in filters. Much like built in reduce functions, the _doc_Ids filter could be built-in. This would allow us to add more built-in filter functions in the future when we discover patterns there.
Exactly. Like we have the "special " reduce functions "_sum" and
"_count" for views for e.g.
>
> 2. POST-ing arguments to _changes. This is needed because there are practical limits on the URL length so we can't send a large number of URL parameters. This is the same reason we have POST to views.
>
> Together, 1. & 2. can solve what you need and they also help us keep the improvements Filipe said could be roll into the replicator while at the same time we don't code ourselves into a corner for future additions.
Instead of a doc_ids parameter to changes, I was thinking that to
achieve the same goal, we could still use the "filter" parameter that
would have a different value for very common cases, starting with an
"_" just like for the special reduce cases. (the list of doc IDs would
then be a regular parameter to the builtin Erlang filter function)
>
> What do you think?
Totally +1
>
> Cheers
> Jan
> --
>
>
> On 13 Oct 2010, at 17:24, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> Hi all,
>>
>> For a project I have to know each time a design doc change and for now
>> I have to create a filter function for each databases created to do
>> that. I think getting changes on specific docids is a common behavior
>> (see replication for example) so I thought to add the possibility to
>> filters changes on docids if a list of documents is passed in the
>> request.
>>
>> ex:
>>
>> POST /db/_changes
>> {"docids": ["id1", ..]}
>>
>>
>> Here is the patch that allows that feature :
>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>
>> What do you think about it ?
>>
>> - benoit
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: filter changes for some docids
Posted by Jan Lehnardt <ja...@apache.org>.
On 18 Oct 2010, at 20:36, Benoit Chesneau wrote:
> On Mon, Oct 18, 2010 at 2:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> I'm thinking: GET /db/_changes?filter=_doc_ids
>>
>> Where _doc_ids references a built in Erlang function that does filtering
>> by doc id. Much like _sum or _count for reduce.
>>
>> How does your scenario differ from this? Maybe I'm just unclear on it.
>>
>
> That's working in my case. Though if for doc_ids we posts i'm not sure
> passing a param is needed in this case since we already define the
> request with a POST and a json body containing a doc_ids member. ALso
> if we want to mix doc_ids + a filter it would be better to handle the
> POST + different params to the filter query argument, I think. In
> other cases that is perfect . I could allows to create for exaample a
> builtin function to get all changed design docs in a db for ex...
I agree for your scenario using the explicit filter *and* a defined JSON
key in the POST body is effectively duplication, but I think my approach
is a bit more general and allows for future scenarios.
I think specifying a built in filter function should work like specifying
a regular filter function, except there's an underscore, as per CouchDB
convention.
I also like the idea of POSTing options to a filter function, but that
should be possible for both custom and built in filter functions.
That's why I think we should use a combination of both mechanisms to
create a solution for your problem while being open for future uses of
the same API.
(Awful lot of starting sentences with "I", so yeah, this is highly
subjective. :)
Either way though, I think we should get this sorted before shipping
1.1.0 or migrating it to a feature branch so we can work on it and
get it right for 1.2.0.
(I talked to Benoit on IRC a bit and he agreed to tackle the changes
I proposed. I'm happy to chip in, if needed.)
Cheers
Jan
--
Re: filter changes for some docids
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Oct 18, 2010 at 2:02 PM, Jan Lehnardt <ja...@apache.org> wrote:
> I'm thinking: GET /db/_changes?filter=_doc_ids
>
> Where _doc_ids references a built in Erlang function that does filtering
> by doc id. Much like _sum or _count for reduce.
>
> How does your scenario differ from this? Maybe I'm just unclear on it.
>
That's working in my case. Though if for doc_ids we posts i'm not sure
passing a param is needed in this case since we already define the
request with a POST and a json body containing a doc_ids member. ALso
if we want to mix doc_ids + a filter it would be better to handle the
POST + different params to the filter query argument, I think. In
other cases that is perfect . I could allows to create for exaample a
builtin function to get all changed design docs in a db for ex...
- benoit
Re: filter changes for some docids
Posted by Jan Lehnardt <ja...@apache.org>.
On 18 Oct 2010, at 12:34, Benoit Chesneau wrote:
> On Sun, Oct 17, 2010 at 7:20 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> Hi Benoit, all,
>>
>> I'm not too happy with how this turned out.
>>
>> There's multiple things this patch is trying to solve and by thinking about them separately, I think we can come up with a cleaner, more future-proof design. I'd like to avoid special casing for situations we think are common but turn out not to be.
>>
>> 1. Built-in filters. Much like built in reduce functions, the _doc_Ids filter could be built-in. This would allow us to add more built-in filter functions in the future when we discover patterns there.
>
> What d you mean by built-in filter ? How would it be called ? If it's
> like _count in reduce function it doesn't solve the case i'm trying to
> solve, ie not creating a function for common case. But I think you
> mean smth like built_in=... , but am not sure it's needed here since
> we have only one case on POST.
>
> So which usage do you expect ? Any example?
I'm thinking: GET /db/_changes?filter=_doc_ids
Where _doc_ids references a built in Erlang function that does filtering
by doc id. Much like _sum or _count for reduce.
How does your scenario differ from this? Maybe I'm just unclear on it.
Cheers
Jan
--
Re: filter changes for some docids
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Oct 17, 2010 at 7:20 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Hi Benoit, all,
>
> I'm not too happy with how this turned out.
>
> There's multiple things this patch is trying to solve and by thinking about them separately, I think we can come up with a cleaner, more future-proof design. I'd like to avoid special casing for situations we think are common but turn out not to be.
>
> 1. Built-in filters. Much like built in reduce functions, the _doc_Ids filter could be built-in. This would allow us to add more built-in filter functions in the future when we discover patterns there.
What d you mean by built-in filter ? How would it be called ? If it's
like _count in reduce function it doesn't solve the case i'm trying to
solve, ie not creating a function for common case. But I think you
mean smth like built_in=... , but am not sure it's needed here since
we have only one case on POST.
So which usage do you expect ? Any example?
- benoît
Re: filter changes for some docids
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Benoit, all,
I'm not too happy with how this turned out.
There's multiple things this patch is trying to solve and by thinking about them separately, I think we can come up with a cleaner, more future-proof design. I'd like to avoid special casing for situations we think are common but turn out not to be.
1. Built-in filters. Much like built in reduce functions, the _doc_Ids filter could be built-in. This would allow us to add more built-in filter functions in the future when we discover patterns there.
2. POST-ing arguments to _changes. This is needed because there are practical limits on the URL length so we can't send a large number of URL parameters. This is the same reason we have POST to views.
Together, 1. & 2. can solve what you need and they also help us keep the improvements Filipe said could be roll into the replicator while at the same time we don't code ourselves into a corner for future additions.
What do you think?
Cheers
Jan
--
On 13 Oct 2010, at 17:24, Benoit Chesneau <bc...@gmail.com> wrote:
> Hi all,
>
> For a project I have to know each time a design doc change and for now
> I have to create a filter function for each databases created to do
> that. I think getting changes on specific docids is a common behavior
> (see replication for example) so I thought to add the possibility to
> filters changes on docids if a list of documents is passed in the
> request.
>
> ex:
>
> POST /db/_changes
> {"docids": ["id1", ..]}
>
>
> Here is the patch that allows that feature :
> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>
> What do you think about it ?
>
> - benoit
Re: filter changes for some docids
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Oct 14, 2010 at 7:05 PM, Filipe David Manana
<fd...@apache.org> wrote:
> On Fri, Oct 15, 2010 at 12:04 AM, Filipe David Manana
> <fd...@apache.org> wrote:
>> Now that we have this, I think I should change the replicator to
>> profit of this _changes feature and allow for continuous replication
>> by doc IDs.
>> Anyone against?
>
> Not only would allow for the continuous replication but also would
> imply removing ugly code from the replicator
> My +1
>
+1
>>
>>
>> On Wed, Oct 13, 2010 at 10:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Wed, Oct 13, 2010 at 6:21 PM, Paul Davis <pa...@gmail.com> wrote:
>>>> On Wed, Oct 13, 2010 at 12:05 PM, Filipe David Manana
>>>> <fd...@apache.org> wrote:
>>>>> For a matter of consistency with the replicator, I would name the
>>>>> field as "doc_ids" instead of "docids".
>>>>>
>>>>> All the rest seems fine to me.
>>>>>
>>>>> On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> For a project I have to know each time a design doc change and for now
>>>>>> I have to create a filter function for each databases created to do
>>>>>> that. I think getting changes on specific docids is a common behavior
>>>>>> (see replication for example) so I thought to add the possibility to
>>>>>> filters changes on docids if a list of documents is passed in the
>>>>>> request.
>>>>>>
>>>>>> ex:
>>>>>>
>>>>>> POST /db/_changes
>>>>>> {"docids": ["id1", ..]}
>>>>>>
>>>>>>
>>>>>> Here is the patch that allows that feature :
>>>>>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>>>>>
>>>>>> What do you think about it ?
>>>>>>
>>>>>> - benoit
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Filipe David Manana,
>>>>> fdmanana@gmail.com, fdmanana@apache.org
>>>>>
>>>>> "Reasonable men adapt themselves to the world.
>>>>> Unreasonable men adapt the world to themselves.
>>>>> That's why all progress depends on unreasonable men."
>>>>>
>>>>
>>>> Looks fine to me. And I'd agree with filipe about using doc_ids for consistency.
>>>>
>>> commited with changes from docids to doc_ids + fixed safari test.
>>> Thank for the review :)
>>>
>>> - benoit
>>>
>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@gmail.com, fdmanana@apache.org
>>
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
Re: filter changes for some docids
Posted by Randall Leeds <ra...@gmail.com>.
Passing the post body makes me nervous. I prefer that the identity of the
filter, for the purposes of checkpoints, be tied to the url alone.
On Oct 16, 2010 5:10 PM, "Benoit Chesneau" <bc...@gmail.com> wrote:
> On Sun, Oct 17, 2010 at 1:40 AM, Filipe David Manana
> <fd...@apache.org> wrote:
>> Reconsidering the doc_ids _changes parameter:
>>
>> I noticed it is mutually exclusive with the filter parameter. That is,
>> if doc_ids is supplied the filter parameter is ignored.
>> Wouldn't it be more interesting if we had an intersection?
>>
>> It could be useful for security reasons as well. A proxy could add the
>> doc_ids parameter or a filter parameter to enforce some security
>> policy.
>>
>>
> I'm not sure intersection is something wanted. _changes need to be
> fast , and filters or doc_ids are already slow down the process.
>
> Also you don't need to have doc_ids and filters, you can simply pass a
> list of doc ids as parameters to a filter function via the query args.
> On the other hand maybe we could allows a POST to be passed as a
> property of a request object to a change filter function ?
>
> - benoit
Re: filter changes for some docids
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sun, Oct 17, 2010 at 1:40 AM, Filipe David Manana
<fd...@apache.org> wrote:
> Reconsidering the doc_ids _changes parameter:
>
> I noticed it is mutually exclusive with the filter parameter. That is,
> if doc_ids is supplied the filter parameter is ignored.
> Wouldn't it be more interesting if we had an intersection?
>
> It could be useful for security reasons as well. A proxy could add the
> doc_ids parameter or a filter parameter to enforce some security
> policy.
>
>
I'm not sure intersection is something wanted. _changes need to be
fast , and filters or doc_ids are already slow down the process.
Also you don't need to have doc_ids and filters, you can simply pass a
list of doc ids as parameters to a filter function via the query args.
On the other hand maybe we could allows a POST to be passed as a
property of a request object to a change filter function ?
- benoit
Re: filter changes for some docids
Posted by Filipe David Manana <fd...@apache.org>.
Reconsidering the doc_ids _changes parameter:
I noticed it is mutually exclusive with the filter parameter. That is,
if doc_ids is supplied the filter parameter is ignored.
Wouldn't it be more interesting if we had an intersection?
It could be useful for security reasons as well. A proxy could add the
doc_ids parameter or a filter parameter to enforce some security
policy.
On Fri, Oct 15, 2010 at 6:52 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Fri, Oct 15, 2010 at 1:05 AM, Filipe David Manana
> <fd...@apache.org> wrote:
>> On Fri, Oct 15, 2010 at 12:04 AM, Filipe David Manana
>> <fd...@apache.org> wrote:
>>> Now that we have this, I think I should change the replicator to
>>> profit of this _changes feature and allow for continuous replication
>>> by doc IDs.
>>> Anyone against?
>>
>> Not only would allow for the continuous replication but also would
>> imply removing ugly code from the replicator
>> My +1
>>
> +1
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: filter changes for some docids
Posted by Benoit Chesneau <bc...@gmail.com>.
On Fri, Oct 15, 2010 at 1:05 AM, Filipe David Manana
<fd...@apache.org> wrote:
> On Fri, Oct 15, 2010 at 12:04 AM, Filipe David Manana
> <fd...@apache.org> wrote:
>> Now that we have this, I think I should change the replicator to
>> profit of this _changes feature and allow for continuous replication
>> by doc IDs.
>> Anyone against?
>
> Not only would allow for the continuous replication but also would
> imply removing ugly code from the replicator
> My +1
>
+1
Re: filter changes for some docids
Posted by Randall Leeds <ra...@gmail.com>.
I don't mean to nag (much), but rather than let the patches get out of
date after you make more changes, would you mind looking at
https://issues.apache.org/jira/browse/COUCHDB-863
and
https://issues.apache.org/jira/browse/COUCHDB-704
They're both small bug fixes to the replication code and the first one
does some code cleanup on shutdown as well.
If there's any issue with them I'll fix it up.
On Thu, Oct 14, 2010 at 16:15, Randall Leeds <ra...@gmail.com> wrote:
> +1
>
> On Thu, Oct 14, 2010 at 16:05, Filipe David Manana <fd...@apache.org> wrote:
>> On Fri, Oct 15, 2010 at 12:04 AM, Filipe David Manana
>> <fd...@apache.org> wrote:
>>> Now that we have this, I think I should change the replicator to
>>> profit of this _changes feature and allow for continuous replication
>>> by doc IDs.
>>> Anyone against?
>>
>> Not only would allow for the continuous replication but also would
>> imply removing ugly code from the replicator
>> My +1
>>
>>>
>>>
>>> On Wed, Oct 13, 2010 at 10:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> On Wed, Oct 13, 2010 at 6:21 PM, Paul Davis <pa...@gmail.com> wrote:
>>>>> On Wed, Oct 13, 2010 at 12:05 PM, Filipe David Manana
>>>>> <fd...@apache.org> wrote:
>>>>>> For a matter of consistency with the replicator, I would name the
>>>>>> field as "doc_ids" instead of "docids".
>>>>>>
>>>>>> All the rest seems fine to me.
>>>>>>
>>>>>> On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> For a project I have to know each time a design doc change and for now
>>>>>>> I have to create a filter function for each databases created to do
>>>>>>> that. I think getting changes on specific docids is a common behavior
>>>>>>> (see replication for example) so I thought to add the possibility to
>>>>>>> filters changes on docids if a list of documents is passed in the
>>>>>>> request.
>>>>>>>
>>>>>>> ex:
>>>>>>>
>>>>>>> POST /db/_changes
>>>>>>> {"docids": ["id1", ..]}
>>>>>>>
>>>>>>>
>>>>>>> Here is the patch that allows that feature :
>>>>>>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>>>>>>
>>>>>>> What do you think about it ?
>>>>>>>
>>>>>>> - benoit
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Filipe David Manana,
>>>>>> fdmanana@gmail.com, fdmanana@apache.org
>>>>>>
>>>>>> "Reasonable men adapt themselves to the world.
>>>>>> Unreasonable men adapt the world to themselves.
>>>>>> That's why all progress depends on unreasonable men."
>>>>>>
>>>>>
>>>>> Looks fine to me. And I'd agree with filipe about using doc_ids for consistency.
>>>>>
>>>> commited with changes from docids to doc_ids + fixed safari test.
>>>> Thank for the review :)
>>>>
>>>> - benoit
>>>>
>>>
>>>
>>>
>>> --
>>> Filipe David Manana,
>>> fdmanana@gmail.com, fdmanana@apache.org
>>>
>>> "Reasonable men adapt themselves to the world.
>>> Unreasonable men adapt the world to themselves.
>>> That's why all progress depends on unreasonable men."
>>>
>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@gmail.com, fdmanana@apache.org
>>
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
>>
>
Re: filter changes for some docids
Posted by Randall Leeds <ra...@gmail.com>.
+1
On Thu, Oct 14, 2010 at 16:05, Filipe David Manana <fd...@apache.org> wrote:
> On Fri, Oct 15, 2010 at 12:04 AM, Filipe David Manana
> <fd...@apache.org> wrote:
>> Now that we have this, I think I should change the replicator to
>> profit of this _changes feature and allow for continuous replication
>> by doc IDs.
>> Anyone against?
>
> Not only would allow for the continuous replication but also would
> imply removing ugly code from the replicator
> My +1
>
>>
>>
>> On Wed, Oct 13, 2010 at 10:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> On Wed, Oct 13, 2010 at 6:21 PM, Paul Davis <pa...@gmail.com> wrote:
>>>> On Wed, Oct 13, 2010 at 12:05 PM, Filipe David Manana
>>>> <fd...@apache.org> wrote:
>>>>> For a matter of consistency with the replicator, I would name the
>>>>> field as "doc_ids" instead of "docids".
>>>>>
>>>>> All the rest seems fine to me.
>>>>>
>>>>> On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> For a project I have to know each time a design doc change and for now
>>>>>> I have to create a filter function for each databases created to do
>>>>>> that. I think getting changes on specific docids is a common behavior
>>>>>> (see replication for example) so I thought to add the possibility to
>>>>>> filters changes on docids if a list of documents is passed in the
>>>>>> request.
>>>>>>
>>>>>> ex:
>>>>>>
>>>>>> POST /db/_changes
>>>>>> {"docids": ["id1", ..]}
>>>>>>
>>>>>>
>>>>>> Here is the patch that allows that feature :
>>>>>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>>>>>
>>>>>> What do you think about it ?
>>>>>>
>>>>>> - benoit
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Filipe David Manana,
>>>>> fdmanana@gmail.com, fdmanana@apache.org
>>>>>
>>>>> "Reasonable men adapt themselves to the world.
>>>>> Unreasonable men adapt the world to themselves.
>>>>> That's why all progress depends on unreasonable men."
>>>>>
>>>>
>>>> Looks fine to me. And I'd agree with filipe about using doc_ids for consistency.
>>>>
>>> commited with changes from docids to doc_ids + fixed safari test.
>>> Thank for the review :)
>>>
>>> - benoit
>>>
>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@gmail.com, fdmanana@apache.org
>>
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
Re: filter changes for some docids
Posted by Filipe David Manana <fd...@apache.org>.
On Fri, Oct 15, 2010 at 12:04 AM, Filipe David Manana
<fd...@apache.org> wrote:
> Now that we have this, I think I should change the replicator to
> profit of this _changes feature and allow for continuous replication
> by doc IDs.
> Anyone against?
Not only would allow for the continuous replication but also would
imply removing ugly code from the replicator
My +1
>
>
> On Wed, Oct 13, 2010 at 10:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Wed, Oct 13, 2010 at 6:21 PM, Paul Davis <pa...@gmail.com> wrote:
>>> On Wed, Oct 13, 2010 at 12:05 PM, Filipe David Manana
>>> <fd...@apache.org> wrote:
>>>> For a matter of consistency with the replicator, I would name the
>>>> field as "doc_ids" instead of "docids".
>>>>
>>>> All the rest seems fine to me.
>>>>
>>>> On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> For a project I have to know each time a design doc change and for now
>>>>> I have to create a filter function for each databases created to do
>>>>> that. I think getting changes on specific docids is a common behavior
>>>>> (see replication for example) so I thought to add the possibility to
>>>>> filters changes on docids if a list of documents is passed in the
>>>>> request.
>>>>>
>>>>> ex:
>>>>>
>>>>> POST /db/_changes
>>>>> {"docids": ["id1", ..]}
>>>>>
>>>>>
>>>>> Here is the patch that allows that feature :
>>>>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>>>>
>>>>> What do you think about it ?
>>>>>
>>>>> - benoit
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Filipe David Manana,
>>>> fdmanana@gmail.com, fdmanana@apache.org
>>>>
>>>> "Reasonable men adapt themselves to the world.
>>>> Unreasonable men adapt the world to themselves.
>>>> That's why all progress depends on unreasonable men."
>>>>
>>>
>>> Looks fine to me. And I'd agree with filipe about using doc_ids for consistency.
>>>
>> commited with changes from docids to doc_ids + fixed safari test.
>> Thank for the review :)
>>
>> - benoit
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: filter changes for some docids
Posted by Filipe David Manana <fd...@apache.org>.
Now that we have this, I think I should change the replicator to
profit of this _changes feature and allow for continuous replication
by doc IDs.
Anyone against?
On Wed, Oct 13, 2010 at 10:10 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Wed, Oct 13, 2010 at 6:21 PM, Paul Davis <pa...@gmail.com> wrote:
>> On Wed, Oct 13, 2010 at 12:05 PM, Filipe David Manana
>> <fd...@apache.org> wrote:
>>> For a matter of consistency with the replicator, I would name the
>>> field as "doc_ids" instead of "docids".
>>>
>>> All the rest seems fine to me.
>>>
>>> On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> For a project I have to know each time a design doc change and for now
>>>> I have to create a filter function for each databases created to do
>>>> that. I think getting changes on specific docids is a common behavior
>>>> (see replication for example) so I thought to add the possibility to
>>>> filters changes on docids if a list of documents is passed in the
>>>> request.
>>>>
>>>> ex:
>>>>
>>>> POST /db/_changes
>>>> {"docids": ["id1", ..]}
>>>>
>>>>
>>>> Here is the patch that allows that feature :
>>>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>>>
>>>> What do you think about it ?
>>>>
>>>> - benoit
>>>>
>>>
>>>
>>>
>>> --
>>> Filipe David Manana,
>>> fdmanana@gmail.com, fdmanana@apache.org
>>>
>>> "Reasonable men adapt themselves to the world.
>>> Unreasonable men adapt the world to themselves.
>>> That's why all progress depends on unreasonable men."
>>>
>>
>> Looks fine to me. And I'd agree with filipe about using doc_ids for consistency.
>>
> commited with changes from docids to doc_ids + fixed safari test.
> Thank for the review :)
>
> - benoit
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Re: filter changes for some docids
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Oct 13, 2010 at 6:21 PM, Paul Davis <pa...@gmail.com> wrote:
> On Wed, Oct 13, 2010 at 12:05 PM, Filipe David Manana
> <fd...@apache.org> wrote:
>> For a matter of consistency with the replicator, I would name the
>> field as "doc_ids" instead of "docids".
>>
>> All the rest seems fine to me.
>>
>> On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>> Hi all,
>>>
>>> For a project I have to know each time a design doc change and for now
>>> I have to create a filter function for each databases created to do
>>> that. I think getting changes on specific docids is a common behavior
>>> (see replication for example) so I thought to add the possibility to
>>> filters changes on docids if a list of documents is passed in the
>>> request.
>>>
>>> ex:
>>>
>>> POST /db/_changes
>>> {"docids": ["id1", ..]}
>>>
>>>
>>> Here is the patch that allows that feature :
>>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>>
>>> What do you think about it ?
>>>
>>> - benoit
>>>
>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@gmail.com, fdmanana@apache.org
>>
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
>>
>
> Looks fine to me. And I'd agree with filipe about using doc_ids for consistency.
>
commited with changes from docids to doc_ids + fixed safari test.
Thank for the review :)
- benoit
Re: filter changes for some docids
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Oct 13, 2010 at 12:05 PM, Filipe David Manana
<fd...@apache.org> wrote:
> For a matter of consistency with the replicator, I would name the
> field as "doc_ids" instead of "docids".
>
> All the rest seems fine to me.
>
> On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>> Hi all,
>>
>> For a project I have to know each time a design doc change and for now
>> I have to create a filter function for each databases created to do
>> that. I think getting changes on specific docids is a common behavior
>> (see replication for example) so I thought to add the possibility to
>> filters changes on docids if a list of documents is passed in the
>> request.
>>
>> ex:
>>
>> POST /db/_changes
>> {"docids": ["id1", ..]}
>>
>>
>> Here is the patch that allows that feature :
>> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>>
>> What do you think about it ?
>>
>> - benoit
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com, fdmanana@apache.org
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
>
Looks fine to me. And I'd agree with filipe about using doc_ids for consistency.
Re: filter changes for some docids
Posted by Filipe David Manana <fd...@apache.org>.
For a matter of consistency with the replicator, I would name the
field as "doc_ids" instead of "docids".
All the rest seems fine to me.
On Wed, Oct 13, 2010 at 4:24 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> Hi all,
>
> For a project I have to know each time a design doc change and for now
> I have to create a filter function for each databases created to do
> that. I think getting changes on specific docids is a common behavior
> (see replication for example) so I thought to add the possibility to
> filters changes on docids if a list of documents is passed in the
> request.
>
> ex:
>
> POST /db/_changes
> {"docids": ["id1", ..]}
>
>
> Here is the patch that allows that feature :
> http://github.com/benoitc/couchdb/commit/fd7829b6b3093ab324a2b5c496600cc6335480b8
>
> What do you think about it ?
>
> - benoit
>
--
Filipe David Manana,
fdmanana@gmail.com, fdmanana@apache.org
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."