From user-return-13482-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Nov 03 18:54:21 2010
Return-Path:
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: (qmail 41347 invoked from network); 3 Nov 2010 18:54:21 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
by 140.211.11.9 with SMTP; 3 Nov 2010 18:54:21 -0000
Received: (qmail 38716 invoked by uid 500); 3 Nov 2010 18:54:51 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 38638 invoked by uid 500); 3 Nov 2010 18:54:50 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 38624 invoked by uid 99); 3 Nov 2010 18:54:50 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Nov 2010 18:54:50 +0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of markjreed@gmail.com designates 74.125.82.180 as permitted sender)
Received: from [74.125.82.180] (HELO mail-wy0-f180.google.com) (74.125.82.180)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Nov 2010 18:54:44 +0000
Received: by wyb32 with SMTP id 32so904985wyb.11
for ; Wed, 03 Nov 2010 11:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:received:in-reply-to
:references:date:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=bd2bB3q4xBBdAQQYfsAPlvmC5QZzg92n2WcMloggS2A=;
b=B1GztjdzuCRV/wUHqoKMYPKWdyl2wItlX2viYGd9IdgSLJrm+OYOFRZknn6Q9Gmj+H
5KLTWIOzQOef1QbDYMilGPbLcXhifL8fniok24z4YewT/jkKFSeDXxWO6+B56MJHfgMQ
S70EOwgUipuUVd5WpsSv3YERtfAJoJJcz0ktE=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:content-transfer-encoding;
b=PeTB8NWKas/Bop3yMks6itpI/ff5rn0e1FBcY6nkrCLJiYYXS81RFYPduYFL1/iR3a
ae3mlrDvyLHcAGmkwfHgQ2QVrauOKV5o8AgfP82JRfAJlv31JlDi3bslc9z4RHqJXSkg
qBb8DSBPl4vQUnVO2VsZ5u5k0ki/vvdi96zyI=
MIME-Version: 1.0
Received: by 10.227.133.75 with SMTP id e11mr13839959wbt.51.1288810461962;
Wed, 03 Nov 2010 11:54:21 -0700 (PDT)
Received: by 10.227.21.2 with HTTP; Wed, 3 Nov 2010 11:54:21 -0700 (PDT)
In-Reply-To:
References:
Date: Wed, 3 Nov 2010 14:54:21 -0400
Message-ID:
Subject: Re: multi columns
From: "Mark J. Reed"
To: user@couchdb.apache.org
Cc: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 3, 2010 at 12:32 PM, sgoto wrote:
> =C2=A0 =C2=A0are there any plans for supporting multi columns in couchdb =
=C2=A0(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.
--=20
Mark J. Reed