- An introduction to CouchDB
- Installing CouchDB
- Experimenting with CouchDB’s web interface
- Integrating with Rails using ActiveCouch
- Integrating with Rails using RelaxDB
- Getting to scaffolding using RelaxDB
- Installing CouchDB from Subversion source code
- Trying out couchrest and topfunky’s basic_model
This afternoon i decided that what the Internet really needs right now is some information about how to connect Ruby on Rails to a CouchDB database. So i’m going to have a go! I don’t quite know what to do (which will probably become very clear!) so this will be a play-along-at-home experience. I’ll blog about it in a series of posts, stopping whenever i get stuck. Hopefully i’ll receive some feedback on whether what i’m doing is a good idea, and get some tips for what to try next.
This first post is just going to be an introduction, stating my interest in wanting to get this to work.
Some brief definitions
For those who don’t know, here are some basic starting points …
Rails is a web application framework, created by David Heinemeier Hansson, written in Ruby, which guides us down an ‘opinionated’ route of best practices such as Model-View-Controller architecture, RESTful techniques, test/behaviour-driven-development. Thanks to its use of conventions rather than configuration, it is easy to get going quickly with Rails. However, it can be quite difficult to break out of the conventions, as we are going to try to do by using CouchDB as the database platform.
CouchDB, from what i can gather, is a document-oriented, RESTful, distributed database system written in Erlang.
Erlang is a programming language from Ericsson, which enables features such as concurrency, soft-real-time access, and fault-tolerance.
More technical details of CouchDB follow …
A popular database model is a relational database, using tables with columns for attributes and rows for data. Rows from multiple tables can be joined using data with matching values, to create relations. MySQL, SQLite, PostgreSQL, Oracle, Microsoft SQL Server and Microsoft Access are examples of relational database systems. Rails, specifically ActiveRecord, works very well with relational data.
Document-oriented databases are different. There is no real hierarchy of data; just a collection of documents which may contain virtually any kind of data. The documents may not necessarily be the same length, as some documents may contain details of fields that other documents do not need to store. In other words, you are not constrained by a database schema.
To query a document-oriented database is to write a view which selects documents and displays them in a particular way. It’s like making a virtual folder in Windows Vista. You can search across all your documents with any criteria you choose – file type, size, last update, tags – and then you can save that search to use again in the future. Of course, it may bring back different results next time you view it, if the data has changed.
I am also fond of the document-oriented database model because i worked extensively with Lotus Notes for many years at IBM.
Representational State Transfer (REST)
REST is a concept that has been becoming very popular over the last few years, probably helped by the embrace it is receiving from the Rails community. When you do something RESTfully, you are performing actions on a resource. There are four basic actions that we might want to use on a resource: create it, read/view it, update it, and delete it. Sometimes this is called CRUD.
These four actions relate very nicely to four HTTP methods. Most web developers know about GET and POST. When we view anything on the Internet we are normally using the GET method to get something from the web server. When we fill in a form and submit data to the web server, we are usually using a POST method. I think that’s why we say ‘blog post’ because it is something we have literally POSTed to the Internet. But there are two other methods that we can use: PUT for when we get something, change it, and put it back, and DELETE for the last of the four CRUD actions.
So we apply the HTTP methods to the resource, indicated by a URI. The point is that the URI stays the same. Suppose i have a resource which is a task, uniquely identified by this URI:
If i GET that URI then i am viewing the task. If i PUT to it then i am updating it. If i send a DELETE request to that same URI then the server will know that i wish to delete the resource.
Working with CouchDB is RESTful by design. Each document is a unique resource. You can GET a document, POST a new one, PUT some updates, and DELETE a document. That’s the way it works. I am guessing that CouchDB must implement its own little web server to respond to the HTTP methods.
A great feature of document-oriented databases is replication. I used to like this about Lotus Notes. The database need not exist in only one place. Everyone who uses it can have their own local copy, if they wish. Using Erlang’s concurrency and fault-tolerance features makes it easy for CouchDB to replicate changes across all copies of the database in a secure and reliable way. Documents, views and indexes can all be kept up to date in soft-real-time (i.e. even if it’s not precisely real-time it’s close enough for the users not to notice that it isn’t). CouchDB handles conflicts at replication time without needing locks.
So what next?
With the introductions over, i am ready to get started on creating a Rails application which runs on a CouchDB database. I have been advised to look at the couchrest library for Ruby, and i am also investigating ActiveCouch which might be a wrapper around the database in the same way that ActiveRecord wraps itself around a database table, extending functionality as a model.
Hopefully it won’t be long before i update again with some results. In the meantime, if anyone has any information, feel free to chime in! :)
When i’m all done with the investigations i hope to write a summary on a wiki somewhere, like, maybe here :)
Part 2: Installing CouchDB