couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <>
Subject Re: [PROPOSAL] new underscore namespacing
Date Tue, 03 Dec 2013 17:48:55 GMT
I'm +1 to the idea of ripping out the metadata fields from the doc bodies
entirely and adding them to the headers. I think this makes a much cleaner
separation of concerns. However, one thing that jumps out at me as a
potential gotcha, is grabbing a large list of conflicts, or some other
piece of metadata that can be much larger than allowable lengths in
headers. We'll need to come up with an approach there, although perhaps
it's a good opportunity to rethink how we bubble up conflicts to users, and
find some way to make it more obvious when there is a conflict.


On Tue, Dec 3, 2013 at 9:25 AM, Brian Mitchell <> wrote:

> On Tue, Dec 3, 2013 at 10:35 AM, Volker Mische <>
> wrote:
> > I personally would prefer to have the meta information completely
> > separate from the document. I know there have been discussion in the
> > past to even have them separate in the backend (but that's not the point
> > of this proposal).
> >
> > So the API for the view function could change to `function(doc, meta)`.
> > This way you could store in your document whatever you like.
> This is convenient in some cases but I really do like how CouchDB
> documents are self-contained and self-representing. Having to rely on
> an outside context to know things like identity and revision seems
> unfortunate.
> Most cases I've interacted with CouchDB would require at least that
> minimal _id and _rev. Separating them might seem okay if you just look
> at a map function with two arguments but it gets messier if you look
> at client code in the applications that use CouchDB. Many do things
> like:
>     my_doc = db.get('doc')
>     ...
>     db.put(my_doc)
> Juggling this context separately will require extra work or at least
> force CouchDB clients to reinvent some way to wrap up and store
> metadata. My experience writing client code against Riak, which
> externalizes this metadata, was not nearly as clean as working with
> CouchDB since everything needed some sort of wrapper where CouchDB
> could many times get away with just a simple value.
> On the side of internals, there is certainly some work to be done to
> lift things in and out of this special field, but it could be done w/o
> forcing clients to live with their world split in two.
> Brian.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message