Industry Figure Tom Chappell

So, as an example of just the latest stumbling block in my Ruby on Rails learning project, I wanted to set up my database tables with proper Foreign Key constraints. But I keep seeing signs that the RoR mainline developers just totally don’t bother with this. Signs like: it’s not really supported very well. But I’m getting ahead of myself.

The Pragmatic Programmers’ Agile Web Development with Rails book had had a link to some guys who had a plugin, several levels of plugins, actually, for supporting FK constraints in migrations. So I took the lowest-level core one, the one that did the least, and hooked it in, and voila, Foreign Key constraints.

And I wrote a controller functional test, which operated on a ‘child’ table (a table that had a foreign key to a ‘parent’ table), and ran it through rake test, and everything was great! The plugin guys had said that if you listed the test fixtures in order from parent table to child table, that everything would work, and it did!

And I wrote another functional test, for the parent this time, and some unit tests for the models…and the world exploded. There were, for one thing, problems tearing down the test data, but (and this was weird), the data was being torn down at the beginning of the tests, rather than at the end of each test. Some time spent with the world’s premier debugging and research tool (starts with a G) turned up a Wiki entry that someone had posted about suppressing FK constraints while tearing down and setting up data. Hm, sounded a little skanky, but at least my actual tests would run with the FK constraints enabled, just like the actual program would. OK.

Retool, retry, and…hey, it almost worked, just one test, of about 60, failed! This was feeling like progress! So, what was the one thing left that was failing? The test_destroy method for the controller that used the parent table. It was trying to delete a record that that was being pointed to by the child table. But WTF? I didn’t even declare the child table’s fixture in my parent table’s controller test!

A great deal of time passed, and in the end, it came down to one committer deciding that if he left a known problem broken, no, if he actually reverted a fix, so that the data from unwanted fixtures that had been used by previous tests would still be left lying around, then he could make the tests twice as fast! And all he had to do was leave it broken!

His justification was that fixtures are really just relics anyway, and that the easy workaround to their being broken was not to use them. I’m not sure, in that case, why it was so vital to speed them up while breaking them again, but then again, I’m not a fricking genius. I am, however, bitter about the hours of my life that I’ll never see again.

Here is the relevant bug ticket. Geez, Louise.

[To be fair, the workarounds that are available are...adequate. I totally have FK constraints in my application, and I'm definitely running rake tests. It wasn't too awful to work around the problem. Just very annoying.]