Archive for the ‘CouchDb’ Category
Unable to replicate from local CouchDB to Cloudant – a quick resolution for the {“error”:”shutdown”} message
Just in case anyone else hits an issue whereby you are unable to replicate a local CouchDB database to Cloudant … I was using Curl on Windows (which never helps of course 🙂 ) and found that I was unable to replicate from a local instance to Cloudant even though my passwords, ca cert bundle, etc. were all correct. Naturally, it took a couple of goes to get the curl escaping on Windows right but even once I’d figured that out it was still failing with the uninformative
{"error":"shutdown"}
I eventually found some posts that pointed to my (very) out-of-date CouchDB instance being the issue: you need to be running CouchDB 1.2.0 preferably on Erlang R15 for this to work correctly.
I upgraded everything and key presto! It works!
Connecting to Cloudant from Erlang: a quick example of using HTTPS from httpc:request
Wiser heads than me will no doubt already know this but I for one struggled with working out how to do this so I thought I’d put the example up in the hope it will help others. So, what I was trying to do was get and put to a Cloudant database from Erlang. Cloudant requires both HTTPS and a username and password and I struggled to find an Erlang example online.
First, make sure that you can connect to Cloudant over curl and fetch at least the _all_dbs resource. If you can’t, Erlang isn’t going to work either. I found that to get curl working correctly, I needed to update the ca cert bundle that came with it.
Here’s how to retrive _all_dbs for your Cloudant account using curl:
curl https://username:password@username.cloudant.com/_all_dbs
where username is your Cloudant username and password is the password associated with your username. For example, if your username were ‘foo’ and your password ‘bar’, here’s the command you would use:
inets:start(),
ssl:start(),
httpc:request (get, {“https://foo:bar@foo.cloudant.com/_all_dbs”, []}, [{ssl,[{verify,0}]}], []).
It is important to remember to start inets and ssl before attempting to use httpc:request. A put to Cloudant is similar, here’s an example that assumes the existance of a database barfoo and a resource widget on your Cloudant instance and also that you have a suitably initialized variable Update which contains the data which you are writing to the widget resource:
inets:start(),
ssl:start(),
httpc:request (put, {“https://foo:bar@foo.cloudant.com/barfoo/widget”, [], [], Update}, [], []).
And there you have it
Restoring CouchDB databases from file
I had a situation recently where I had the database files for several CouchDB databases backed up in source control but no longer had the actual databases available to clone.
What I needed to do was to restore my databases onto a different machine using the database files that were in the source repository.
As it turns out, this is actually pretty simple although not well documented.
CouchDB stores its data files in %COUCHDB%\var\lib\couchdb\ which on my Windows VM equated to C:\Program Files (x86)\Apache Software Foundation\CouchDB\var\lib\couchdb
In order to restore my databases from source control (or any other source where you have stored the physical files for that matter), it was simply a matter of copying them to C:\Program Files (x86)\Apache Software Foundation\CouchDB\var\lib\couchdb
Open Futon afterwards and there are your recovered CouchDB files. Simples!
Curl returning “Invalid UTF-8 JSON” error from CouchDb on Windows although JSON is correct
I have been playing around with CouchDB for a while now but early on hit a problem with some of the examples in O’Reilly’s “CouchDB: The Definitive Guide”: Curl, when used on Windows, kept giving an “Invalid UTF-8 JSON” error even though the JSON itself was correct.
The example I was trying to use was taken from the O’Reilly book:
curl -X PUT http://username:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af -d '{"title":"There is Nothing Left to Lose","artist":"Foo Fighters"}'
The database albums existed and the username and password were correct … so what was going on? Turns out it was an issue with escaping quotes in the cmd shell in Windows … Basically, use double instead of single quotes for the JSON string being posted and escape all quotes within that string with \”:
curl -X PUT http://username:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af -d "{\"title\":\"There is Nothing Left to Lose\",\"artist\":\"Foo Fighters\"}" {"ok":true,"id":"6e1295ed6c29495e54cc05947f18c8af","rev":"1-4b39c2971c9ad54cb37e08fa02fec636"}
Obviously, replace username and password values with your actual user name and password but this example will work.