Ripple 0.8 is Full of Good Stuff

by Sean Cribbs

It’s been a while since I’ve blogged about a release of Ripple, in fact, it’s been a long time since I’ve released Ripple. So this post is going to dig into Ripple 0.8 (released today, August 31) and catch you up on what has happened since 0.7.1 (and 0.5 if you don’t follow the Github project).

The major features, which I’ll describe in more detail below, are:

Riak 0.12 Features

The biggest changes here were some bucket-related features. First of all, you can define default quorum parameters for requests on a per-bucket basis, exposed as bucket properties. Riak 0.12 also allows you to specify “symbolic” quorums, that is, “all” (N replies), “quorum” (N/2 + 1 replies), or “one” (1 reply). Riak::Bucket has support for these new properties and exposes them as attr_accessor-like methods. This is a big time saver if you need to tune your quorums for different use-cases or N-values.

Second, keys are not listed by default. There used to be a big flashing warning sign on Riak::Client#bucket that encouraged you to pass :keys => false. In Ripple 0.8 that’s the default, but it’s also explicit so that if you use the latest gem on Riak 0.11 or earlier, you should get the same behavior.

Runs on Rails 3

I’ve been pushing for Rails 3 ever since Ripple was conceived, but now that the actual release of Rails 3 is out, it’s an easier sell. Thanks to all the contributors who helped me keep Ripple up-to-date with the latest prereleases.

Linked associations

These are HOT, and were the missing features that held me back from saying “Yes, you should use Ripple in your app.” The underlying concepts take some time to understand (the upcoming link-walking page to the Fast Track will help), but you actually have a lot more freedom than foreign keys. Here’s some examples (with a little detail of how they work):

class Project
  include Ripple::Document

  property :name, String
  key_on :name

  many :developers  # creates a linked association

class Developer
  include Ripple::Document

  property :handle, String
  key_on :handle

  many :projects   # also linked
  one :credential  # embedded!

class Credential
  include Ripple::EmbeddedDocument
  property :public_key, String

project = => "ripple")
sean = => "seancribbs")

project.developers << sean  # sean is saved, project is not
                            # sean does NOT receive back link automatically
project.robject.links # #<Set: {</riak/developers/seancribbs>; riaktag="developers"}>          # saves project, with new link

# Meanwhile, in another session...
project = Project.find("ripple")
project.developers  # Invokes project.robject.walk({:bucket => "developers", :tag => "developers"}) and instantiates the objects

You’ll notice only one and many in the above examples. From the beginning, I’ve eschewed creating the belongs_to macro because I think it has the wrong semantics for how linked associations work (links are all on the origin side). It’s more like you “point to one of” or “point to many of”. Minor point, but often it’s the language you choose that frames how you think about things.

Session stores

Outside the Ruby-sphere, web session storage is one of Riak’s most popular use-cases. Both Mochi and Wikia are using it for this. Now, it’s really easy to do the same for your Rails or Sinatra app.

For Sinatra, Padrino and other pure Rack apps, use Riak::SessionStore:

# your
require 'rack'
require 'sinatra'
require 'riak-sessions'

use SomeRackMiddleware
use Riak::SessionStore

run MySinatraApp

For Rails 3, use Ripple::SessionStore:

# your config/application.rb

require 'riak-sessions'

module MyApplication
  class Application < Rails::Application
    config.session_store = ::Ripple::SessionStore


If you’re curious what’s coming next in Ripple, or to provide feedback on the direction, be sure to check out the issue tracker. As always, questions can be sent direct to me (sean AT basho DOT com) or to the riak-users mailing list. Documentation is available on Github Pages.


© 2006-present Sean CribbsGithub PagesTufte CSS