
ActiveRecord has grammar issues and you’re just going to have to deal with it.
Nobody likes a grammar stickler. Even Stannis Baratheon knew that correcting others grammar was a bad look, and he had all the tact of a dictator fighting to gain control in a power vacuum…oh, wait…

First, a quick rundown of naming conventions in ActiveRecord. When a model is used to create a table, Ruby uses its built-in pluralize method to name the table. The Model Class is named using the singular form in CamelCase, with the first letter of each word capitalized and no spaces. The Database Table in turn is named using the plural form in snake_case, with underscores separating words and all letters downcased.

The conversion of user-named, singular models to their plural forms is handled by Ruby’s built-in pluralize method. As you can see from the example table provided (taken from Ruby on Rails’ own guide), these conversions handle many of the idiosyncratic pluralizations found in the English language. However, it doesn’t always do what you think it will, or what is grammatically correct.
Want to check out the method’s functionality yourself? You can build a simple run file to see how Ruby will pluralize any string. The gem being required here is ActiveSupport, which holds the pluralize method among many others.

This method nails some of the harder irregular plurals, including millenium (millenia), axis (axes), knife (knives), fish, and sheep. Other times it can give one of a few choices (octopus; octopuses, octopi, octopodes), or give the less often used but still accepted form (deer; deers.) In many cases, though, it is just simply wrong. Some of the interesting returns included “gooses”, “mooses”, and “passerbies.” This method also defaults to pluralizing the last word if the string has more than one, whether it is grammatically correct to do so or not.

So, beyond the novelty, why is this important? Convention is king in Ruby, so knowing how Ruby’s conventions are set up and operate can help you debug or even catch naming issues preemptively. For me personally, issues with these conventions cropped up while working with ActiveRecord without the use of Rails. I came across the error below while trying to migrate tables during a pair programming assignment.
ActiveRecord::StatementInvalid: Could not find table 'equipment'
In this specific case, my partner and I had actually made the mistake of incorrectly pluralizing equipment to “equipments” when setting up our migrations. Ruby was calling out our mistake by looking for the correctly named table “equipment,” which didn’t exist. We searched for a way to tell ActiveRecord to look for our incorrectly named “equipments” table instead.
Many of the solutions we came across invoked methods or functionality that is already built in to Rails, but for this specific project we were working with ActiveRecord outside of Rails. This meant that most of those solutions, such as modifying our environment.rb file or calling the set_table_name function, would not work for our application.

We ended up using the table_name method as a class method to explicitly set the table name. While in our case we used it to get our class to communicate with our incorrectly named table, you could also utilize it to fix issues involving table names that Ruby has pluralized incorrectly. As it does not change the actual table name in any way, just the pathing to it, it can be used in cases where table names cannot be updated. Ruby conventions aren’t going to change, so you’re just going to have to be the one to adapt.
