On 08/01/2009, at 1:24 PM, Paul Davis wrote:

[..]
function(doc)
{
   for(var field in doc)
  {
      emit([field, doc._id], doc[field]);
  }
}

I call that an "exploded index" and worry somewhat about its storage usage.

Two concerns:

- you'd be needlessly re-storing the large data that the OP wanted to avoid transferring. Presumably it's big. You might be able to manually exclude it if it always has the same name, of course - if there's a lot of records with a lot of small fields, index overhead might double or even triple the database size

An alternative might be to take the reverse to that approach, and write a view which returned all the field except the large entry (if known) you're trying to avoid transferring. That way, you'd avoid having to re-store those large fields in the index as well.

Storage is cheap*, but obviously it would be bad practise to needlessly double (or worse) the database size.

I have often wondered the exact overhead of a row in a view index. Obviously, if it's more than a few bytes, it's going to be a factor to consider when contemplating view index strategies which generate an awful lot of index rows. If there are a large number of fields with a small amount of data in each, and a large number of documents, it is quite plausible the "exploded index" could be several times the original size of the data.

Anyone with inside knowledge want to chip in on that? What would be the approximate overhead, per-entry, of an exploded view index as described by Paul? Or maybe I should just test it, since I've been wondering about that for a while ...


Sho

* good storage is not actually cheap



Then to access a specific property:

http://127.0.0.1:5984/db_name/_view/view_name/by_property? key=["foo", "docid1"]

HTH,
Paul Davis

On Wed, Jan 7, 2009 at 4:18 PM, Robert Koberg <[email protected]> wrote:
Hi,

first, couchdb is just beautiful! :) (using 0.8.1-incubating from MacPorts)

I am very new, and have read the available docs and several blog posts.

Can you drill into a doc with a simple GET?

Say I have a doc like:

{"_id": "a", "_rev": "123", "foo":{"bar": 1}, "big-ass-prop": "huge amount
of stuff"}

Ideally I would like to be able to call something like:

http://127.0.0.1:5984/mydb/a/foo

to return {"bar":1} and avoid downloading "big-ass-prop"

Is this or something like it possible?

(I realize "foo" is a 'sibling' of the _id in the document, but it is
probably treated more like a parent in the DB?)

If not possible, is it possible to create some kind of default
action/filter/? that does something like the above? That is, reads the request uri, recognizes it is a document and that there is extra path info
which should be used to resolve a property.

thanks,
-Rob


Reply via email to