Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of carl.bourne@me.com designates
 17.158.236.119 as permitted sender)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Subject: Re: Summary view for Pie Charting
From: Carl Bourne <carl.bourne@me.com>
In-reply-to: <46CC7BBD-5AEC-449A-9F80-68E1AC4BB047@couchbase.com>
Date: Thu, 20 Sep 2012 08:04:05 +0100
Content-transfer-encoding: quoted-printable
Message-id: <2A199735-20B9-4E24-9EF0-1BE43A649075@me.com>
References: <08180A01-8DC0-491C-8976-B75BBB5F95F4@me.com>
 <46CC7BBD-5AEC-449A-9F80-68E1AC4BB047@couchbase.com>
To: user@couchdb.apache.org

Jens,

Understand!=20

So I guess then the only way to do this is using 3 separate queries with =
startkey, endkey for each time period? Then assemble the results =
externally using whatever performed the query?

Are there any other options?

Regards,

Carl


On 20 Sep 2012, at 01:18, Jens Alfke <jens@couchbase.com> wrote:

> This isn=92t a valid map function, because it=92s not purely =
functional =97 it uses external input in the form of the current =
date/time. So if the map function is run twice on the same document, it =
will not always emit the same output. That=92s not allowed.
>=20
> In other words, think of what happens if you generate the index now, =
and then query it 90 days from now. The information in the index =
probably won=92t be valid because everything will have expired already, =
right? But CouchDB has no idea the index is time-sensitive, so it=92s =
going to return you the old data anyway. You just cannot put =
time-sensitive data into a map function.
>=20
> Instead what you should be doing in the map is writing out the =
expiration times of the documents. Then at query time you can see how =
far in the future those are.
>=20
> =97Jens