Some Rails plugins: Real FK

I have mostly shifted my main development language to Ruby, as most of the work I do tends to be pretty well covered with Rails. That’s not new, however - What is new is that I feel I have got to the point where I actually have something to share. And it feels very good. So my next couple of posts (three, actually) will be covering some plugins I’ve written. They are, of course, just sketched - but they work reliably enough to be deemed as useful by their author ;-) Today I will start by blogging about RealFK. Of course, I will be copying from its documentation/description - I wrote it as well, so I’m not really plagiarizing my own site. I’m not suing self. You can of course also browse the RealFK SVN tree.

References

Rails is built upon a "dumb database" concept. Rails assumes the database will not force restrictions upon the user - i.e. that the model validators are all there is. But I disagree ;-) I was raised with PostgreSQL, not with MySQL, and I do believe the database can and should impose sane values - It should impose trust on the data.. So, if you want to create a relation field, properly acting as a foreign key and refering to another table, instead of doing it via the ActiveRecord::ConnectionAdapters::TableDefinition#column (or even ActiveRecord::ConnectionAdapters::TableDefinition#references) methods, declare them with add_refrence: def self.up create_table :proposals do |t| (...) end create_table :proposal_types do |t| (...) end create_table :proposal_statuses do |t| (...) end add_reference :proposals, :proposal_types add_reference :proposals, :proposal_statuses, :null =>false, :default => 1 end The corresponding fields (proposal_type_id and proposal_status_id, respectively) will be created in proposals, and the RDBMS will impose a Foreign Key constraint. The references can be removed via remove_reference, i.e., for inclusion in down migrations: def self.down remove_reference :proposals, :proposal_types remove_reference :proposals, :proposal_statuses drop_table :proposal_statuses drop_table :proposal_types drop_table :proposals end Of course, in this case the remove_reference call is not really needed - But if you are dropping a table that is referred to from a table that will remain existing, you will have to remove the foreign key constraints (that is, the referring columns).

Join (HABTM) tables

When you define a simple has_and_belongs_to_many (HABTM) relation in your model, you are expected to create an extra table representing this relation. This is a very simple table (i.e. it has only a row for each of the related table‘s IDs), and it carries foreign key constraints. Please note that join tables are not supposed to carry any extra columns - If you need to add information to join tables, think twice and better use a has_many :elements, :through => :othermodel declaration, and create the othermodel table manually. To create a HABTM table representing that each person can attend many conferences and each conference can be attended by many people: def self.up create_table :people do |t| (...) end create_table :conferences do |t| (...) end create_habtm :people, :conferences end def self.down drop_habtm :people, :conferences drop_table :people drop_table :conferences end The last call will create a conferences_people table (according to Rails’ conventions, table names are sorted alphabetically to get the join table‘s name). Note that in this case, in the down migration, the drop_habtm call must appear before the drop_table calls, as it carries foreign key constraints.