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 B

As Principal of Subimage LLC, Seth spends most of his days improving Cashboard. Occasionally he finds time to write about music, design, startups, and technology.

Tagged: ruby, rails