Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 585F79DCD for ; Tue, 25 Sep 2012 20:02:47 +0000 (UTC) Received: (qmail 12297 invoked by uid 500); 25 Sep 2012 20:02:45 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 12196 invoked by uid 500); 25 Sep 2012 20:02:45 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 12188 invoked by uid 99); 25 Sep 2012 20:02:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Sep 2012 20:02:45 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.161.180 as permitted sender) Received: from [209.85.161.180] (HELO mail-gg0-f180.google.com) (209.85.161.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Sep 2012 20:02:39 +0000 Received: by ggmi2 with SMTP id i2so2324367ggm.11 for ; Tue, 25 Sep 2012 13:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=W0PTAeRBddj0dciDGCZeWDU0Qll+JnpBizCjheG0X88=; b=y0lYfdh39Fwqx/1a7Nk1Z1JYClzFvgm9kc9Gh1QABnM6o3XUzRnJRwSISpKhxdM9uz l8+Cazjb5Us8fhiMekuGLlScRR8fYDJ6x3Z18nIrL4MX+cu5z3e6QIij6SeMAj5Q1UhR Ed4nN51ghLAwARCHH/aukzk3SNob/ryXbF+E93/DtUpQJFgxZdaKV3jkEblsrOL8BwPK CxsHgYtsnBOdCiJBFCPc2AtddkdiG+iHvt56f8hzg6PhH3kKlOjTqSl9jS7ojfU6HJq4 CJtkIi8s7YbjR6rtdJITjpyHhxvsypTC+0khsHezzyTmFiire1UuD8rSeDD5SwhljcNU XnFA== Received: by 10.52.70.140 with SMTP id m12mr2595615vdu.20.1348599769245; Tue, 25 Sep 2012 12:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.112.197 with HTTP; Tue, 25 Sep 2012 12:02:09 -0700 (PDT) In-Reply-To: References: <6D6F51F2-9DE5-4CBB-9FB0-9511A863B972@apache.org> From: Paul Davis Date: Tue, 25 Sep 2012 14:02:09 -0500 Message-ID: Subject: Re: following fast doc updates To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Alternatively, you could use two dbs. One db you could write "change requests" to (each request as a new doc) and then listen for changes on that and apply them in that logic. This also has that added benefit that you could do the timestamped dbname pattern for your changes feed dbs to (possibly depending on use case) remove some of the cruft buildup. On Tue, Sep 25, 2012 at 1:31 PM, Mark Hahn wrote: >> The _changes feed only ever shows leaf revisions > > AARRGGHH. I am so screwed. I have been working on a scheme that relies on > tracking every change. And as everyone knows there is normally no way to > find out what changed in a doc. I am going to have to add a history of > changes to each doc which it not only wasteful, but a pain to implement. > > Thanks for taking the trouble to give me bad news. > > > On Tue, Sep 25, 2012 at 10:19 AM, Adam Kocoloski wrote: > >> On Sep 24, 2012, at 5:16 PM, Mark Hahn wrote: >> >> > If I update a particular doc multiple times rapidly, is each update >> > guaranteed to show up in a continuous changes feed? I am worried that >> the >> > change feed will be optimized to just show the latest value of a doc with >> > multiple updates. This would break my logic. >> >> Your worries are justified. The _changes feed only ever shows leaf >> revisions (i.e., latest updates to branches of the edit tree). Regards, >> >> Adam