Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 11157 invoked from network); 5 Sep 2009 15:43:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Sep 2009 15:43:19 -0000 Received: (qmail 81860 invoked by uid 500); 5 Sep 2009 15:43:18 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 81778 invoked by uid 500); 5 Sep 2009 15:43:18 -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 81768 invoked by uid 99); 5 Sep 2009 15:43:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Sep 2009 15:43:17 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akat.metin@gmail.com designates 209.85.218.211 as permitted sender) Received: from [209.85.218.211] (HELO mail-bw0-f211.google.com) (209.85.218.211) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Sep 2009 15:43:09 +0000 Received: by bwz7 with SMTP id 7so1459738bwz.11 for ; Sat, 05 Sep 2009 08:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=19nF+HWxsQWvsfKOiquE5RY7mim/ZR1TdjhM1Ktl1PQ=; b=Hqct/FHzCDCZELcccZFHQBkvP4pQo7zshIxssqshqV495zZ7n/KzC9D0c99/abWBAT jVHiokRgEgqI4SN/F7ElJj4mgIxa3QxCJmY7AoVNMTe6ezl6ewXFW5a85vZfWTorsuQ1 5iuKf4M0bdN+4JhaYOqeYdkrX9G7ccxoGR0DA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hK09Uy/vskjyCvLcA+TbpKzv5HuhFLyYLOHkD5Usl9dZxyQh8G57GqK4Uab6/UKO7T 1xMnHzlL6fOHZpFgy0uvAbGTeDcENCYFGrUKOvCPnha+tQYm+X5UKTISnO0FrHRDueyq NvH3Vz2zDHf4219jefpuv6htQHvFiE47XvQOQ= MIME-Version: 1.0 Received: by 10.103.127.32 with SMTP id e32mr5274171mun.70.1252165368437; Sat, 05 Sep 2009 08:42:48 -0700 (PDT) In-Reply-To: References: <98a246a10909030535r59b1ecc2m32bfb1b0dc93fe46@mail.gmail.com> <98a246a10909030606q4c02cfe1id2312054bea11b04@mail.gmail.com> <98a246a10909042334i38fbd7ccu5446ce8f7950881f@mail.gmail.com> Date: Sat, 5 Sep 2009 18:42:48 +0300 Message-ID: <98a246a10909050842o3a45fd8bj3eceedeb002ec522@mail.gmail.com> Subject: Re: Tree structure: how to calculate branch node sum, using results from a view that calculates leaf node sums. From: Metin Akat To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Sat, Sep 5, 2009 at 10:20 AM, Chris Anderson wrote: > On Fri, Sep 4, 2009 at 11:34 PM, Metin Akat wrote: >> One way I can think of is to bulk update all transactions "belonging" >> to a leaf account when moving that leaf account around. >> I can live with having to wait some time till this gets executed. >> Is this "bad thinking" or is it OK to some extent? >> > > It can be problematic if you need ACID compliance as bulk updates > aren't transactional. (Especially consider what can happen during > replication.) > > This can often be remedied in your app model, but this is can get complex. > So this probably means that the least problematic way to go would be if I calculate aggregate balances client side. OK, for now I don't plan having millions of accounts, so I'll choose this way after all.