How to use basic Active Record Associations

For the third phase of Flatiron Coding Bootcamp, we learned the Ruby programming language which has a bunch of interesting and useful methods as well as helpful libraries. One of those libraries that help significantly with dealing with databases and manipulating data is Active Record.

Active Record is an Object Relational Mapper. It connects objects of an application to tables in a relational database management system. Using Active Record, you can easily access and manipulate data and their properties from a database without using much code or explicitly writing SQL statements. This is where Active Record Associations come in. To quote from the Official Ruby on Rails guide for Activer Record Associations, “An association is a connection between two Active Record models. They make common operations simpler and easier in your code.”

For my third phase project, I decided to create a web app that allows you to log your workout without all of the extra fluff that those apps tend to have.

In my app, I had two models, one for Workouts, and the other for exercises. A workout in this case means a single day or routine for a specific for certain body parts, say leg day for example. So a workout will have many exercises, and exercises are part of a workout. Therefore, I needed to use the belongs to, and has many associations.

The dependent option here means that when I call destroy on an instance of a workout, all the exercises associated with that workout will also be destroyed. Very useful!

The has_many association indicates that each instance of a workout contains zero or more instances of the exercise model. Similarly, the belongs_to association indicates that each instance of an exercise belongs to a certain workout model. Sidenote, you may wonder why Exercise does not have many workouts, after all, certain exercises are used in multiple workouts for many routines. This is because all though that may be true, chances are that the number of sets, reps, and weight for the same exercise will be different depending on the day (strength day vs hypertrophy day).

Given that an exercise belongs to a workout, the exercises table needs to have the foreign key for knowing which workout it belongs to. The migrations look like so:

Here I am using t.belongs_to instead of explicitly writing t.workout_id because it is more efficient in querying the database since it creates an index of workout_id

Once you have your associations and migrations done, you now gain access to a ton of default methods that allow you to query your database with much less code. The methods are also much more intuitive than SQL queries. Even working through labs, I would occasionally try methods that I didn’t know existed and they worked. Libraries like Active Record, Rake, and Sinatra, make Ruby a pleasure to use and navigate through data. Although I still prefer JavaScript, I had a great time learning Ruby in this phase of my coding bootcamp.