Oct 25
2009

Making Workling::Return::Store predictable

This took me about 4 hours to figure out today, so I figured I might as well blog about it.

I'm using the Workling / Starling combo to handle background processing tasks on Cashboard for various things.

One of those things is the Cashboard / Basecamp project sync, which provides a really nice progress bar while it does it's thing.

I was encountering unpredictable results when I started refactoring some code from the worker into various models, and stumbled upon this oddity.

>> Workling.return.set('foo', 'bar')
=> "STORED\r\n" 
>> Workling.return.get('foo')
=> "bar" 
>> Workling.return.get('foo')
=> nil

I expected Workling.return.get to be a non-destructive action, but I was dead wrong. It turns out that the default Memcache Workling::Return::Store client acts like a first-in-first-out (FIFO) stack on each key.

Adding these methods allow me to use any Workling::Return::Store as I initially expected. This will add the methods to the default MemoryReturnStore (for testing), and the StarlingReturnStore (for dev/production).

Now I can run the following code with no problem.

>> Workling.return['foo'] = 'bar'
=> "STORED\r\n" 
>> Workling.return['foo']
=> "bar" 
>> Workling.return['foo']
=> "bar"

Hopefully this helps someone bashing their head against the wall, like I was. Don't hurt yourself.

Written by Seth Banks

Seth spends most of his days leading the design team at Green Bits and improving Cashboard. Occasionally he finds time to write about music, design, startups, and technology.

Tagged: ruby, rails