Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4928E58C.4070000@silencegreys.com>
Date: Sun, 23 Nov 2008 00:09:32 -0500
From: Jedediah Smith <jedediah@silencegreys.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: couchdb-user@incubator.apache.org
Subject: Re: sums by date view
References: <4928BDBE.5000801@silencegreys.com>
 <C04B9B05-83A2-48DC-9D5C-5AD9526AC29E@apache.org>
In-Reply-To: <C04B9B05-83A2-48DC-9D5C-5AD9526AC29E@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Jan Lehnardt wrote:
> If you query `_view/viewname`, you get the total sum of all `doc.amount` 
> instances.
> 
> If you are using [2008, 11, 22, 21, 01, 00] for the date you can do:
> 
>  - query `_view/viewname?group_level=1` to get all amounts per year
>  - query `_view/viewname?group_level=2` to get all amounts per months
>  - etc...

This would only give you the net difference for the given time period, 
not the absolute balance in the account. To get the balance for date d 
you need "sum(doc.amount) where doc.date < d".

A possible compromise would be to use group_level to find the balance 
per component and then add those together on the client. Example:

balance(2008-11-22) =
   sum(-inf to 2007-) +
   sum(2008-01- to 2008-10-) +
   sum(2008-11-01 to 2008-11-22)

Or is this what you meant?

A less arbitrary grouping method could also be used like converting the 
date to a second count and grouping by individual bits.

This doesn't quite meet my criteria but would at least make better use 
of view indexes, assuming they work like I imagine they do. If a view 
like the above existed and I updated an old transaction, there would 
only be one rereduce for each group level, right?