Taking your cucumber tests back to the future with Delorean

I’m currently working on an API for Vquence’s VQdata product which allows our customers to use a REST interface to retrieve videos with certain keywords they have previously stored. While writing tests I need to be able to mock out the Time object so that my tests were deterministic relative to time.

I remembered listening to a Ruby5 podcast which mentioned a great little gem called Delorean.

Delorean easily allows you to mock time in your tests. In no time I had hooked it up to cucumber.

In features/support/delorean.rb:

require 'delorean'  
# Make sure we fix the time up after each scenario
After do

and then in features/step_definitions/delorean_steps.rb

Given /^I time travel to (.+)$/ do |period|

this lets me create steps like

  Scenario: Link attributes are correct for yesterday
    Given I time travel to 2010-02-01 05:00
    When I GET the videos keywords feeds page
    Then I should see "start_time=2010-02-01T00:00:00"

Some other examples you can use with Delorean are

  • 2 weeks ago
  • tomorrow
  • next tuesday 5pm

You can find more examples in the Chronic gem documentation which Delorean uses to achieve this functionality.

Changing the type on a legacy table in ActiveRecord

I’m doing some work for a client which involves extracting some data from a legacy database and displaying it in a web interface. One of the fields in the table is the number of megabytes included in the quota. For some crazy reason this is defined as follows:

  bandwidth_in_included DECIMAL(8,2)

This means that in the web interface I get 10,000.0 MB instead of 10,000 MB. Notice the decimal point. Also I wanted bytes rather than MB since the legacy app was a bit all over the place in this regard.

My first solution was to simple create a virtual attribute in the model to override the type.

class Quota < ActiveRecord::Base

  # We need it as an int and in bytes
  def bandwidth_in_included
    attributes['bandwidth_in_included].to_i * 1000


This worked great except that I’m actually rendering the data to XML to be accessed over a REST service so this was generating XML elements like


Eventually I discovered that you can tell ActiveRecord to override the type, so I ended up with

class Quota < ActiveRecord::Base

  # We want to treat the bandwidth_included a an integer
  class << columns_hash['bandwidth_in_included']
    def type

  # We need it as an int and in bytes
  def bandwidth_in_included
    attributes['bandwidth_in_included].to_i * 1000


bzr-svn and svn revisions

I was updating an svn branch today using bzr, thanks to bzr-svn, and I wanted to know what svn revision I was at.

You can easily see the bzr revision by running

johnf@zoot:~/trunk$ bzr revno

But it gives no indication of where you are in SVN land. After a bit of rummaging around I discovered the following

johnf@zoot:~/trunk$ bzr version-info
revision-id: svn-v3-trunk0:90e61fa5-4541-0410-a685-e5b9dba3c764:trunk:74
date: 2008-05-29 19:24:44 +0000
build-date: 2008-06-14 19:10:59 +1000
revno: 34
branch-nick: trunk

The revision-id field seems to be the key and seems to indicate I’m using SVN revision 74. Checking the branch via the web confirmed that.

Rails, ActiveRecord, MySQL, GUIDs and the rename_column bug

Since I wasted over 4 hours of my life today working my way through this problem I feel the need to share.

Since it seems to be the in thing in the Web 2.0 space, just to be cool, we use GUIDs to identify different objects in our URLs at Vquence. For example my randomly created vquence on on Rails has a GUID of


Andy Singleton has written a rails plugin called funnily enough guid. This allows you to do the following in your model.

class Vquence < ActiveRecord::Base
  usesguid :column => 'guid'

Once you do this you will automatically get GUID looking identifiers in the db and your application. The guid column in the DB gets mapped to Vquence.id so you can do things like


We used to use Sphinx as our search index, we now use Lucene. Sphinx requires that you have an integer id for each document in your index. This is to make your SQL queries much faster. The dumb way to create your index is to use queries like the following.

SELECT * FROM videos LIMIT 0,10000
SELECT * FROM videos LIMIT 10000,10000
SELECT * FROM videos LIMIT 990000,10000

I know this as its what we originally used with Lucene. This works fine until you reach about 1,000,000 rows. The problem is that since there is no implicit ordering or range in the above query it means that for the final query MySQL needs to workout what the first 1,000,000 rows are and then return you the last 10,000.

A much better way to do it is the following

SELECT * FROM videos WHERE integer_id >= 1 and integer_id < = 10000
SELECT * FROM videos WHERE integer_id >= 10001 and integer_id < = 20000
SELECT * FROM videos WHERE integer_id >= 990000 and integer_id < = 1000000

This is fast as long as integer_id is indexed.

So to accommodate this in Rails we began using migrations like the following.

class Videos < ActiveRecord::Migration
  def self.up
    create_table :videos do |t|
      t.column :uuid, :string, :limit =>22, :null => false

    add_index :videos, :uuid, :unique => true
    rename_column :videos, :id, :integer_id

  def self.down
    drop_table :videos

This was all done months ago and the repercussions didn’t rear their ugly head until today. Previously everything in the videos table had been created by our external crawler and Rails never needed to insert into the table. Today I wrote some code that inserted into the videos table and everything broke horribly.

The problem is that ActiveRecord can still see the integer_id field and tries to insert a 0 value into it. It isn’t clever enough to realise that it is an auto increment field and to leave it alone. After some help from bitsweat on #RoR I implemented a dirty hack to hide the integer_id column from ActiveRecord. Thanks to Ruby overriding the ActiveRecord internals is really easy and I added the following to our guid plugin.

  # HACK (JF) - This is too evil to even blog about
  # When we use guid as a primary key we usually rename the original 'id'
  # field to 'integer_id'. We need to hide this from rails so it doesn't
  # mess with it. WARNING: This means once you use usesguid anywhere you can
  # never access a column in any table anywhere called 'integer_id'

class ActiveRecord::Base
    alias :original_attributes_with_quotes :attributes_with_quotes

    def attributes_with_quotes(include_primary_key = true, include_readonly_attributes = true)
      quoted = original_attributes_with_quotes(include_primary_key = true, include_readonly_attributes = true)

So this worked like a charm and after 4 hours I thought my pain was over, but then I tried to add second row to my test database. This resulted in the following.

 Mysql::Error: Duplicate entry '0' for key 1: INSERT INTO `videos` (`updated_at`, `sort_order`, `guid`, `description`,
 `user_id`, `created_at`) VALUES('2008-01-11 16:45:05', NULL, 'bcOMPqWaGr3k5CabxfFyeK', '', 5, '2008-01-11 16:44:28');

I ran the same SQL with MySQL client and got the same error. I then looked at the table and saw the following

mysql> show columns from moo;
| Field      | Type        | Null | Key | Default | Extra |
| integer_id | int(11)     | NO   | PRI | 0       |       |
| guid       | varchar(22) | NO   | UNI |         |       |

What I expected to see was

mysql> show columns from moo;
| Field      | Type        | Null | Key | Default | Extra          |
| integer_id | int(11)     | NO   | PRI | NULL    | auto_increment |
| guid       | varchar(22) | NO   | UNI |         |                |

The difference is that when the column was renamed it seems to have lost its auto increment and NOT NULL properties. Some investigation showed that the SQL being used to rename the column was

ALTER TABLE `videos` CHANGE `id` `integer_id` int(11)

when it should be

ALTER TABLE `videos` CHANGE `id` `integer_id` int(11) NOT NULL AUTO_INCREMENT

It seems that this is already filled as a bug on the rails site, including a patch.

Funnily enough that bug is owned by bitsweat. It seems he’s managed to help me out twice in one day đŸ™‚ It doesn’t seem that it made it into Rails 2.0 though so until then be careful about renaming columns using migrations.