Convention vs Configuration
30 Sep 2013One of the ‘best practices’ that’s been going around is that convention is better than configuration. Meaning that writing manually or somehow generating automatically a configruation file describing in detail how two things link together - like a database table and a model in an ORM - is less efficient than having a convention for how it works and to let it work like that automatically, with no configuration files anywhere. I have sort of mixed feelings on this right now, and will probably have more to say about it at some point.
For now, I have the opinion that, when you’re on the right side of it and following the conventions in the way that it expects, everything just works in a way that seems almost magical. On the other hand, the people who make these things don’t seem to be very good about documenting the supposed conventions anywhere, and if you happen to accidentally do something in a way that breaks the conventions, the result is usually total chaos that’s painful to debug. More of a mess and time sink than having the configuration files in the first place? I suppose that depends on your experience with the technology. If you have used it a lot and really know the conventions, then you’ll probably spend most of your time on the beautiful magic side, but when you’re a newbie, dealing with figuring out how you got yourself into a mess and how to get out of it, then it seems like more trouble than it’s worth. I’m inclined to push through anyways, but it can be a pain at the time.
In light of that, I thought I’d document something that I’d been finding to be a headache lately - Ruby ActiveRecord capitalization/pluralization conventions. ActiveSupport has methods for converting words between CamelCase
and underscore_case
, and for pluralizing and singularizing words, and ActiveRecord uses them aggressively to convert names of table and columns between various standards. It’s nice most of the time, but it can be a minefield too - get a word format wrong somewhere, and it tends to blow up in a way you wouldn’t expect. So after some headaches and research, here is the name format that ActiveRecord expects for table names everywhere you might use them:
rails generate (tablename)
- singular camelcase- actual database table name - plural underscore
- class name - singular camelcase
- model file name - singular underscore
belongs_to
- singular underscorehas_many
- plural underscore- reference column name / foreign key in other tables - singular underscore of foreign table suffixed by
_id
- name in references in migration - singular underscore
- method on parent object - plural underscore
For example, say you want a model named ReportFile. Work would go as so:
- Generate it with
rails generate model ReportFile ...
- The model class name will be
ReportFile
, and it will be stored in the filereport_file.rb
. - The database table generated by the migration will be named
report_files
. - If you link another table to it using
belongs_to
orhas_one
, then it will be called:report_file
, and there will be areport_file
getter and setter on that model - If you link another table to it using
has_many
, then it will be:report_files
, and there will be areport_files
getter and setter on that model - If you link another table to it using
belongs_to
, then the foreign key in that table will be namedreport_file_id
- When writing a model generate statement and referencing the table, it will be
report_file:references
- The migration file will have the line
t.references :report_file