Re: Questions about changes feed

[Marco Monteiro <ma...@textovirtual.com>]

When you want to delete the document, save it with the additional property
"_deleted"  with the value true.
This deletes the document but keeps the properties that the document has,
which can then be used in the filter.

Marco

On 26 October 2010 04:38, kowsik <ko...@gmail.com> wrote:

> On Mon, Oct 25, 2010 at 7:57 AM, Adam Kocoloski <ko...@apache.org>
> wrote:
> > On Oct 24, 2010, at 10:10 PM, kowsik wrote:
> >
> >> I have a few questions about the _changes feed.
> >>
> >> 1. How many changes are kept around for each DB? Obviously, not
> >> everything, but is it the last 100, 1000 or some other configurable
> >> limit?
> >
> > The most recent edit of each branch of every document is kept around
> forever, or until a new edit on that branch occurs.
>
> Thanks Adam. A follow up observation (enhancement request really): I
> like the way the filter code gets the document so it can use the
> req.query to only push certain notification to certain clients.
> Unfortunately when a document gets deleted all I get is something like
> this:
>
>
> {"seq":389,"id":"8f8bb53dbf8eb9be81923fea21072386","changes":[{"rev":"2-30b513fc78ad7eadd4db4b7f87591338"}],"deleted":true}
>
> It would be nice to have the actual doc be part of this so that the
> filter can be more intelligent in its routing decision. For example,
> only notify certain interested clients about the deletion.
>
> Thanks,
>
> K.
> ---
> http://www.pcapr.net
> http://twitter.com/pcapr
> http://labs.mudynamics.com
>

Re: Questions about changes feed

[Benjamin Young <be...@couchone.com>]

Marco, be careful about adding anything to a doc with an "_" in it as that's
a reserved "namespace" for CouchDB's own use.

That said, creating your own "trash" system on top of CouchDB (for
interested party notification, etc), is not a bad pattern. However,
depending on the existence of deleted docs for later filtering isn't great
as compaction would kill those off completely.

"_deleted: Indicates that this document has been deleted and will be removed
on next compaction run"

So they may not be there long enough to matter. You could avoid compaction,
but that's the road to an un-relaxing future. :) Better to implement a
compaction safe model on top of CouchDB, IMO.

Later,
Benjamin

On Tue, Nov 2, 2010 at 2:45 PM, Marco Monteiro <ma...@textovirtual.com>wrote:

> When you want to delete the document, save it with the additional property
> "_deleted"  with the value true.
> This deletes the document but keeps the properties that the document has,
> which can then be used in the filter.
>
> Marco
>
> On 26 October 2010 04:38, kowsik <ko...@gmail.com> wrote:
>
> > On Mon, Oct 25, 2010 at 7:57 AM, Adam Kocoloski <ko...@apache.org>
> > wrote:
> > > On Oct 24, 2010, at 10:10 PM, kowsik wrote:
> > >
> > >> I have a few questions about the _changes feed.
> > >>
> > >> 1. How many changes are kept around for each DB? Obviously, not
> > >> everything, but is it the last 100, 1000 or some other configurable
> > >> limit?
> > >
> > > The most recent edit of each branch of every document is kept around
> > forever, or until a new edit on that branch occurs.
> >
> > Thanks Adam. A follow up observation (enhancement request really): I
> > like the way the filter code gets the document so it can use the
> > req.query to only push certain notification to certain clients.
> > Unfortunately when a document gets deleted all I get is something like
> > this:
> >
> >
> >
> {"seq":389,"id":"8f8bb53dbf8eb9be81923fea21072386","changes":[{"rev":"2-30b513fc78ad7eadd4db4b7f87591338"}],"deleted":true}
> >
> > It would be nice to have the actual doc be part of this so that the
> > filter can be more intelligent in its routing decision. For example,
> > only notify certain interested clients about the deletion.
> >
> > Thanks,
> >
> > K.
> > ---
> > http://www.pcapr.net
> > http://twitter.com/pcapr
> > http://labs.mudynamics.com
> >
>