Emergent Ruby Object Persistence with Redis February 17, 2010 Tweet
I’ve been playing a lot with Redis lately and I really like it. There’s just something about building my application data “schema” with Redis that just feels right. So simple, but SO much power.
But alas, when attempting to build applications lately I find myself not confident in the mechanisms I’m using to map Ruby objects to Redis key-values. At first I wanted to build something DataMapper-esque; specifying property mappings and “relationship-y” kinds of things. But constructing my persistent objects this way felt like way too much “upfront design”; too much coupling to a “pattern” that doesn’t really make sense when storing data in a key-value database. I wanted just enough API to make it easy to put stuff into Redis without me losing the “connection” to storing keys.
A concrete example: namespacing. Redis::Namespace handles this by proxying your Redis connection with a top-level namespace. I think this works really well for an application like Resque with a “flatter” data model. My “schemas” tend to be designed more like those in the Redis tutorial on creating a twitter clone. So my keys tend to look like foo:bar:UID:attribute for objects that are a Foo::Bar and I want to make this dead simple to do.
Enter Rubis. Rubis is really a play-place right now. Nothing too serious; a bit of a sidetrack while attempting to build some Ruby applications with Redis. The initial focus will be two-fold: simple object attribute to namespaced key-value storage and an API that enables emergent designs rather than over-specification. Hopefully in the next week or two you will see that design come to fruition.
Also, I’m attempting to take the vow of 100% TDD with this project. I’ve already failed a little, but so far I’ve definitely come much farther than ever before. Maybe you will help me stay on the wagon with this? Or is it “off the wagon?” I can never remember.
As with most of my projects is this mostly a learning experience it. Something Dave Hoover calls “Breakable Toys”; a practice I’ve enjoyed for a while, but now forcing myself to push to open source much quicker.