Active Record is used often within the Ruby on Rails framework, but by itself, it is a ruby gem that can be installed to use in our projects. Its purpose is to connect our Ruby models with tables in a database. Why would we want to use Active Record? Well, firstly, Active Record is an ORM, which essentially means there’s no language barrier when communicating with a database through our models. So, we can use Ruby to query our database as opposed to some version of SQL language for example. Active Record is translating for us, to save us a couple headaches and make our lives as developers much less complicated.
To reiterate, Active Record is the bridge linking our Ruby models and the rows in our database tables. Simply installing the gem gives us access to an entire new library of code to help us walk this bridge. Then we use class inheritance to give us access to this new library of methods, making our Ruby class a subclass of ActiveRecord::Base. Doing so, we can now use these new methods, like “.create” or “.find”, to query our database. We also no longer have need of Ruby’s attr_accessor method, as Active Record lets you set or get attributes merely once you’ve retrieved it.
When you’re working on a project with a backend, chances are you’ll need multiple models that are related to each other in various ways. Examples include belongs to, has many, has many through, etc. Active Record, again, makes our lives easier by helping with making these associations. First, writing migrations to create our database takes few lines of easy-to-understand code. When writing these migrations, depending on that model’s relationships, we may need to include another column for our table: a foreign key. It’s a simple concept, where we are denoting the relationship between our models. For example, a Bookshelf model may have many books, and a Book model, will belong to a Bookshelf. How can we know where our book belongs? A foreign key — in this case called a “shelf_id”, perhaps. To help us query our database to, say, get a Shelf’s books, or a Book’s shelf, we use these foreign keys together with Active Record macros.
In its essence, a macro is a method that writes some code for us. Much like Ruby has its attr_accessor macro, Active Record has its own for us to use to specify model relationships, giving us access to methods based on the relationship specified. In this example, our Bookshelf class is of course inheriting from ActiveRecord::Base, so we can now use these macro methods, and then all that’s needed is another simple line of code: has_many :books. Our Book class, then, is almost exactly the same besides the given macro: belongs_to :shelf. Our Shelf now knows it can have many books, and our Book class now knows the objects it produces will belong to a Shelf. These macros have now given us the ability to now associate our individual book and shelf objects with each other. If we added a new book object to our database and saved it under a variable, maybe ‘emma’, and a new shelf, ‘classics’, we can easily put emma on this shelf by saying: emma.shelf = classics. Simple as that. Because of our macro association methods, our emma book knows which shelf it belongs to (based on its shelf_id, which was given when we associated emma with classics), and vice versa. So saying “classics.books” would return our classics shelf object with all associated books, and “emma.shelf” would thusly return our classics shelf!
As should be evident by now, Active Record is very powerful. With very simple lines of code, we’ve created associations between our Ruby models and persisted those associations in our database. Active Record took our migrations and our macros and created a myriad of new methods for us to seamlessly communicate with our database to create, delete, edit, or simply show us whatever we’ve queried.