CouchDb is transactional. Documents, when saved, are either all or nothing. You cannot have a half saved document, or a file attachment partially updated. File attachments are written concurrently, and then committed. If there is a conflict, the update is aborted. Compare this to regular updating a file on the file system read by multiple users.

For, for acid compliance, CouchDb has all the properties:
Atomic – Commits are all or nothing
Consistent – Documents and views are always a complete representations of a point in time.
Isolated – Writes by multiple concurrent updates aren’t seen by others until completely commited.
Durable – the disk design of CouchDb is append-only storage which emoves the need for shutdown logic of fixup logic.

]]>By: Janhttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45547
Fri, 07 Sep 2007 09:01:27 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45547@aranwe CouchDb handles distribution, replication, conflict-detection, fast reporting, fulltext search, authentication, quick (as in concurrent) storage and a lot more. I don’t see where HTML or XML files give you all this. Above all, just convert your XML documents to JSON and dump them into CouchDb and you’re all fine. JSON is just waht CouchDb uses internally. This is a good thing because it keeps our code smaller an cleaner since we don’t have to do all the XML handling in the DB. You can still do that, though and JSON is an easy, yet complete, enough format to do so.
]]>By: Janhttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45546
Fri, 07 Sep 2007 08:57:03 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45546@Daniel CouchDb doesn’t use Mnesia or Dets but a custom storage module. Your view of the data remains consistent during you fetching or adding. Not having permanent connections doesn’t mean you don’t have connections. CouchDb’s storage module does all that is promised by ACID and there’s no way, other than disk failure, that CouchDb loses your data after it reports a safe write. Also, you’re the first to mention transactions here or anywhere in the CouchDb documentation.
]]>By: aranwehttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45545
Wed, 05 Sep 2007 23:54:58 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45545I realize this may be a pretty stupid point to make, but how is this any different than just creating static html or using xml with xquery? I’m having a hard time seeing the point of building ‘yet another document storage format.’ Don’t we have enough to choose from yet?

Also, while the openness of the format may work well with only one or a few people updating the documents, trying to help a large number of people create views into an undefined schema would be a nightmare. I am sure this will find a small following, but I can’t imagine this making huge waves.

]]>By: Daniel Lyonshttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45544
Wed, 05 Sep 2007 18:16:46 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45544It doesn’t seem entirely fair to me to claim ACID compliance when you do not support connections. If I cannot stay connected, in what sense is my view of the data consistent and in what sense are my changes isolated to my connection? Furthermore, durability is a matter of implementation (is there any way that you could lose the data after you tell me my transaction is complete?) If compound operations of my devising cannot be bundled into atomic transactions, a claim of transaction support is extremely misleading. So I’d like to know in what sense CouchDB is ACID compliant, or even transactional. These properties are not automagically inherited from merely using Mnesia or Dets as your storage backend.
]]>By: Jan Lehnardthttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45543
Mon, 03 Sep 2007 19:16:29 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45543@Sam excellent. Damien, CouchDb’s author worked on the Notes core server. Go figure :-) And getting data out _is_ easy.
]]>By: Samhttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45542
Mon, 03 Sep 2007 18:28:03 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45542Sounds kind of like Lotus Notes. Notes was fine for getting data into it and working with it. However when you wanted to get the data out it was a massive pain.
]]>By: Jan Lehnardthttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45541
Mon, 03 Sep 2007 15:36:25 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45541@Mike CouchDb is not meant to replace relational databases. It uses just a different approach to storing and retrieving data that might or might not suit your requirements, beliefs or preconceptions.

…and I bet this will work much faster than with CouchDb …

is not much of an argument either, sorry :-)

CouchDb is just another tool in your workbench.

]]>By: Mike Borozdinhttp://www.sitepoint.com/watch-out-for-couchdb/#comment-45540
Sun, 02 Sep 2007 13:40:21 +0000http://www.sitepoint.com/blogs/2007/08/30/watch-out-for-couchdb/#comment-45540I see no point in this. Document management can still be done with any relational databases and I bet this will work much faster than with CouchDb that seems to be more a technology prospect now than an actual implementation, because if the idea proves valuable it will be takenover by huge databases producers.

The need for de-normalisation, particularly in document management is due to volume more than anything else. I work with a few DB’s that are several terabytes in size each, and the only way to get the performance increases we need is to de-normalise data by splitting it into tables of similarly grouped data (eg. date based).

This doesn’t prove that it will work any faster with CouchDB at least with this implementation.