Tim Parkin wrote:
The upshot appears to be that CouchDB is limited to only changing a
single document at a time through a user interface (unless you want to
add lots of work to handle conflicts).. Could I have a confirmation of
this so I can blog about it. It's a pretty fundamental restriction and
one I'm sure people who want to use CouchDB would want to know about.
I'm just a CouchDB user, not remotely affiliated with the project; but
as I said before:
1. We should move this to user@
2. Atomic activity is at the single document level. If the data has
relations then you may need to add lots of work to handle conflicts.
That is a fundamental restriction, one which people who want to use
CouchDB would want to know.
IMO the documentation and the book and the buzz indicate this, and God
knows if you spend any time writing an application, it becomes
immediately obvious. Not to mention that it should be apparent to a
developer that you will have to write more application code when you can
no longer just lock everything in sight, have a party with your data,
and then unlock whenever is convenient. I am interested in CouchDB
despite all those for two reasons:
1. Some applications don't need a relational model. For example,
revision control or wikis fit CouchDB well because they are mostly
append-only applications, and there is very little conflict resolution
logic (you outsource that to the users).
2. If you want to scale up and you choose CouchDB or a similar tool,
at least you are going into things with your eyes open. You admit that,
yes, it will take more work up front to build up the data-handling code,
but it pays off down the road when you can scale out.
So in short: yes, but it's worth the trade-off for some applications.
--
Jason Smith
Proven Corporation
Bangkok, Thailand
http://www.proven-corporation.com
