couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rune S. Larsen (JIRA)" <>
Subject [jira] Commented: (COUCHDB-390) proposed additions to _changes feed
Date Thu, 06 Aug 2009 13:18:15 GMT


Rune S. Larsen commented on COUCHDB-390:

Custom made  "_changed"-functions could be handled like views and kept in design-documents
for easy deployment.

Idea:     /<dbname>/_design/<design-name>/_changed/<filterfunction>/


You can already identify creations because _rev will start with "1-"  - at least when _rev
is assigned automaticly. Still it could be a nice feature to see if the doc was C/U/D.

> proposed additions to _changes feed
> -----------------------------------
>                 Key: COUCHDB-390
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>            Reporter: eric casteleijn
>            Priority: Blocker
> The _changes comet feed as a replacement for the update notifications is a great step
forward, but I'm currently missing these features:
> 1. The feeds are now per database, rather than per server, which is nice in some use
cases, but in others it's preferable to have a server wide feed (In the case of many thousands
of databases on a server, and a single process reacting to updates, by putting messages on
a message queue for instance). Ideally I'd like to have both server wide and per database
_changes feeds available.
> 2. I'd like to have a configurable _changes feed that let's me declare what data will
be output in the update rows in the feed, in a similar way to writing views.
> 3. I'd like to (optionally) have information on whether a particular update was a document
creation, update or deletion, so clients would be able to react to those differently without
needing to query into the database to find out what happened. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message