couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark J. Reed" <>
Subject Re: multi columns
Date Wed, 03 Nov 2010 18:54:21 GMT
On Wed, Nov 3, 2010 at 12:32 PM, sgoto <> wrote:
>    are there any plans for supporting multi columns in couchdb  (eg update
> one column for a key without re writing the entire row) ?

I think it's misleading to refer to CouchDB documents as "rows", since
each of them can have a completely unique set of "columns".  I suppose
every set of attributes on some doc in a database can be considered as
the schema for an abstract table containing all the docs with that set
of attributes, but it's a bit of a stretch, especially when you get
into overlapping attributes.

Anyway, CouchDB doesn't have this feature.  I disagree with sgoto that
the crash-only design prohibits it, however. Certainly the server
would have to append the entire modified record to the data store, but
that doesn't mean the entire document has to go over the wire back and
forth between the server and the client.  As long as the modification
was anchored to a specific _rev, it would just be shorthand for the
GET, PUT sequence currently required.

I second the recommendation for MongoDB, which has good support for
both in-place document modification and ad-hoc querying.  The
"reliability and/or deployment complexity" comes down to a few key
differences between Couch and Mongo:

   - Mongo is not crash-only; in fact, a standalone Mongo instance has
no reliability guarantees whatsoever.  You need to always use
clustering if you want to avoid losing or corrupting data.
  - Clustering is a little more involved to set up than CouchDB
replication, and master/master is still experimental
  - It uses a binary client/server protocol, software for which needs
to be installed wherever clients run

So it's different, but a good system that might fit your use case better.

Mark J. Reed <>

View raw message