Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Wed, 11 Jul 2012 11:31:27 +0100
From: Rory Franklin <rory@chillibean.tv>
To: user@couchdb.apache.org
Message-ID: <F043A7641F5B42C0AF8A888C4A846627@chillibean.tv>
Subject: Large key's in views
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="4ffd55ff_5c482a97_4acd"

--4ffd55ff_5c482a97_4acd
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We have a tree structure stored in Couch to mimic a filesystem, and I am =
trying to determine the most efficient way to calculate storage amounts f=
or any node (and below).

As each leaf contains its path up to the root node, would it be bad form =
to emit out the path with a value of the sum of the contained files withi=
n that node, considering that node depth could be huge=3F (although in re=
ality would rarely go more than 20 levels deep, more often would be less =
than 10 levels)

So it could look like this:

emit(=5B=226a1b6034bc634e3cf6865da4780c39eb=22, =22d70c3dc615aaa3065e2edd=
4ecd9af74b=22, =226a1b6034bc634e3cf6865da4780c50ad=22 =E2=80=A6=5D, 50030=
203)

=46rom there I can do a startkey/endkey query to get all nodes below a ce=
rtain point and do a reduce to get the total file size.

My worry is that they emitted key being very large could be problematic, =
but I guess this would only impact on how much storage the view will use =
on disk=3F


Rory
--4ffd55ff_5c482a97_4acd--