Rails with foreign key constraints
I don’t think it’s completely fair to say that Ruby on Rails is wedded to MySQL, but I do think it is fair to say that often its approach to solving problems is influenced by the mindset that circulates around the MySQL database world. Foreign keys are one such case. For me, they are a necessary thing to maintain the very basic level of refferential integrity in a relational database. Without them, often, database can become lost or misplaced inside the database when things are moved around.
Having said that, there are definately some issues related to them, as well as the ease-of-development problems that come into play. Over in the caboo.se, atmos looks at the impact of constraints on testing and how Rails does test database management. This is something I’ve run into already, and I solved it the way I’ve always dealt with foreign keys in my development process: they are added last for production use. I actually use standard Ruby schema migrations to deal with the development process, and then at the end as the last step, I add the constraints onto the database layer.
This is definately sub-optimal in my mind, but right now, it’s the only way to handle it. I also have the issue that I’ve not patched up the schema dumper to move some PostgreSQL specific data-types (inet, etc) from development to test, so I have to double run rake migrate, once for development, and another time for test. Minor problem, but I’m about ready to just fix up the dumper so it works right—for me at least, and then release the changes in a plug-in.
Overall, though, I tend to enforce integrity both with the bits and pieces in Rails, but also in the database for the most patently obvious things. It might not deal with certain situations correctly, but it keeps me from shooting myself in the foot on more than a few occasions. Like security, integrity is a layered approach.
This entry was posted at 3:45 pm on 1 May 2006 and is filed under Ruby. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
I agree as well—I would have migrated from a legacy PHP-wrapped system already, but I expected Rails to be more sensible about foreign keys.
Both comments and pings are currently closed.
I totally agree with you on the MySQL influence on Rails, which I think otherwise is a fantastic framework.
I’m developing a do-over of a fairly complex system from PHP/Postgresql in Rails, and so far the biggest snag I’ve run into is the way that Rails assumes I am building columns such as “Type”, and “Status” into my tables as simple varchars. This is the wrong way to do it. Instead, “Type” and “Status” columns should be integers referencing foreign keys in respective “Types” and “Statuses” tables. The application code should never be responsible for data integrity at this level. Not only should the database do this, it’s built to do it.
What this means for me in Rails, is that many of the nice automagic features, such as Single Table Inheritance, only half-work.
I am however starting to think about patching ActiveRecord to support a more proper way of doing things.