I've been migrating some of the database of a project here at work to CouchDB.  The first great thing about CouchDB is that since it is all HTTP, the "driver" to interface with it is dead simple.  All you need is a JSON parser and something to tack on HTTP headers and send the string to the socket.  Or just a HTTP library, yeah, thats how most people do it (but a "HTTP client library" isn't much more than some URL encoder and some string concatenation).

I'm using a great little package, SCouchDB in Pharo Smalltalk for my work, which is the former and works great and is pretty fast.  Anyway I just wanted to post about a few surprising things I've already started doing after using CouchDB for only a week.

1. Some of the data didn't get migrated correctly (it was an error in my code in object initialization overwriting some instance variables).  I just needed one attribute from every object in the old database copied over to CouchDB.  Since I didn't need to copy the entirety of every object, I just created a new document in the database with a JSON array of id -> value pairs so my code could suck in the array and update the attribute with the value on all documents with the id.

The cool part is that in CouchDB 1.0 (really > 0.11) you can replicate individual documents.  So I just have an SSH tunnel to the CouchDB on the server, replicate the document and suck in the data on the server.  This is great because I can replicate the server database to my laptop, mess around with the data locally without fear of losing any of it, then replicate only what is needed back up to the server.  I deleted the document when i was done with it.

2. In order to replicate the production database back to my dev. environment I've had to delete my local data occasionally because I've deleted documents locally that are still on the server (and I want to have them on my machine again).  However I have some design documents in my local database that I still want to keep.  So I just replicate the design documents I want to keep into another local database, delete the local db entirely, replicate the server db to my local db then replicate the design docs back to the working local db.

The replication is so easy and trivial that I've started using it for things other than just replicating data like I outlined above.  It is literally easier for me to replicate a document from one CouchDB to another than it is to export the data to a file and copy the file around.

CouchDB is a wonderful product to work with because of its simplicity.  It works in obvious ways and is just the right mixture of features to be incredibly useful yet simple and reliable.  It reminds me of the feeling when I first discovered Ruby years ago.  The principle of least surprise is a refreshing thing to have in a database for the web, sorry, of the web.

P.S. To those who might suggest I use MongoDB instead: I chose CouchDB because of its reliability (append-only file storage) with one server running and some things I'll do with it later to improve page-load times, like generating HTML snippets in the database for example.  Also, you can't argue with the simplicity of interfacing via HTTP!