(void* dan)

Many Ruby on Rails decisions are guided by the motto “convention over configuration.”  This makes Rails opinionated software and allows one to get up and running quickly and easily, so long as you follow the crowd.  I love this.  It makes you confident you can try something new, get it up and running fairly easily, then start adding functionality, breaking and tweaking iteratively.  They so to err is human.  It’s also Rails…

I’m a very organized person; it helps me get things done.  So when I recently started building some Rails billing functionality, I decided I would namespace it.  Shouldn’t be too bad…

script/generate model billing/Account ...

This created the model Billing::Account in the file models/billing/account.rb.  Nice.  Turned out to be less-than-nice when I tried to start working with it.  I’ll spare you the details of how much I hated my life that day and get straight to the caveats:

1. The migration generated created a table called “billing_accounts” which seemed correct (and great!) to me.  But ActiveRecord doesn’t care about your namespace, so you have to manually add “table_name :billing_account” to the Billing::Account model.
2. For testing, a new directory was created: test/fixtures/billing, but it was empty.  The file billing_account.yml was added to the base fixtures directory.  Don’t do what I did and move that file into the billing/ directory: those fixtures don’t get loaded.  So leave it, or move it and update Rails’ load path to look through fixtures/ recursively.
3. Foxy fixtures do not work with namespaced models.  Not at all.  If there’s a way to get them to play nice, I couldn’t figure it out before deciding to hand out a couple of id’s manually.  Fuck it, that’s why.

It puzzles me that Rails’ generator seems to handle namespaced models so gracefully, but actually creates these incompatible time-sucking gremlins.  Did I do something completely wrong here?