On Sat, Nov 22, 2008 at 9:09 PM, Jedediah Smith <[EMAIL PROTECTED]> wrote: > > 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) >
This looks like the right way to combine multiple time ranges to me. Adding on the client is a fine thing in a case like this. However, I think you can do it in a single query. > If a view like the > above existed and I updated an old transaction, there would only be one > rereduce for each group level, right? Querying with group=false will be faster, I think. (I should benchmark this...) In the normal case, with a modest amount of data, that's about right. Each grouped view query (I think... I really should bust out the log() in the views to know for sure...) will fire at least one JavaScript rereduce. In the case of very very much data and a first time reduce query over that range, the rereduce could run a few times, but the # of rereduces run should increase only logarithmically with the # of rows, if I'm not mistaken. It's only when you run multiple queries (or multple reduces for groups within a range) that you're likely to run into a linear increase in the number of rereduces. Again, this should be explored in the log, but I think you'll get a minimum of 1 rereduce per group query. The simplest query to get someone's running balance would be something like: _view/viewname?startkey=["bob", BEGINNING_OF_TIME]&endkey=["bob", CURRENT_DATE] which has an implicit reduce=true&group=false. BTW Jan I really like your array date format. -- Chris Anderson http://jchris.mfdz.com
