CouchDB on Rails (part 1 of ?)

  1. An introduction to CouchDB
  2. Installing CouchDB
  3. Experimenting with CouchDB’s web interface
  4. Integrating with Rails using ActiveCouch
  5. Integrating with Rails using RelaxDB
  6. Getting to scaffolding using RelaxDB
  7. Installing CouchDB from Subversion source code
  8. 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 …

Ruby is an open-source, interpreted, object-oriented programming language created by Yukihiro Matsumoto (‘Matz’).

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 …

Document-oriented database

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.

Document-oriented database diagram

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.

CouchDB stores documents as JavaScript Object Notation (JSON). This has a three-fold advantage: it is easy for humans to read, fast for computers to parse, and lightweight to send across a network (compared with XML). I like JSON.

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:

http://site.com/tasks/1

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.

Distributed

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

Advertisements

56 comments on “CouchDB on Rails (part 1 of ?)

  1. Hi Paul, ah, that looks good! It’s the most complete tutorial i’ve seen so far.

    One question … you seem to be using CouchDB as if it were a relational database, with separate models for posts and ratings. This makes a lot of sense because Rails/Merb are well trained to deal with this sort of design. But how about nesting ratings within a post document … could you do that?

    For another example, see my part 3 about tracks on a CD. I use nested JSON to include them in the CD document. CouchDB is delighted to accept that sort of format. How might RelaxDB handle it?

  2. Aimee, yep, you could do – example below. RelaxDB embodies merely one way to use CouchDB – that it promotes an object / id approach may or may not be appropriate depending on an application’s needs. As of this afternoon, it also offers experimental support for explicit denormalisation.

    class CD “The Holy Pictures”)
    tracks = []
    tracks < “I Heard Wonders”, “length” => “5:35”}
    tracks < “Story Of The Ink”, “length” => “5:23”}
    thp.tracks = tracks
    thp.save

    thp = RelaxDB.load(thp._id)
    puts thp.tracks[1][“title”]

  3. Hi Paul, nice job, thanks!

    Oh yeah, WordPress swallowed a lot of your code, didn’t it! Thanks for the Friendpaste link. I notice Friendpaste is powered by CouchDB! Awesome! :)

  4. Pingback: CouchDB resources | Tech Mix

  5. You’re an unusually good writer, Aimee.

    Thanks for this series of posts. I’m looking forward to the next 6 (that exist so far).

  6. Wow, thanks Mark! I’ve unfortunately not done any CouchDB lately, just haven’t had the time … but i definitely intend to come back to it and finish off this series.

  7. Pingback: plok

  8. Hi Aimee,

    I was looking for some kind of help on start using CouchDB with Rails when fortunately Google brings me here.

    I start following you in this series today, and for sure will enjoy the ride.

    Thanks a lot.

  9. Pingback: couchdb: couchdb 101 | breaker of stuff, destroyer of things

  10. Pingback: Random tinkering « Jabberwocky

  11. Pingback: CouchDB Ruby Libraries « Semergence

  12. I first saw this on the python-list. Someone (sorry, couldn't remember any way to dig back a name) gave an explanation that I found really reasonable: the space disambiguates that from a float e.g. 3.040Marble Host

  13. Pingback: Comiezo a ver Apache CouchDB « Feedverse

  14. 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.

  15. Hi Aimee.I appreciate your all attemps.In Japan, I have few information about CouchDB on Rails.Your series of posts help a lot.Thanks!!

  16. I was looking for some kind of help on start using CouchDB with Rails when fortunately Google brings me here.I start following you in this series today, and for sure will enjoy the ride.Thanks a lot.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s