ELI5: ActiveRecord::Edition
… or — explain in ~more digestible~ terms.
If you would have told me that in just two weeks of the Immersive Software Engineering program at Flatiron School that I would actually feel like a “real coder”, then I would have not believed you. The amount of knowledge that I have been able to somewhat comprehend has surprised not only me, but the rest of my cohort.
With that being said, every day brings its (new) challenges, and this week’s hurdle was *drum roll please* ACTIVE RECORD! A week of dozens of OOP labs prepared me for this moment. It took me days of re-reading readme’s, rewatching lectures, and creating my own AR models for me to finally get a greater grasp on its true purpose and why AR is truly a life-saver (and a time-saver).
What is Active Record?
Active Record is a Ruby gem that works as an Object Relational Mapper to help facilitate actions and create databases, better organizing your domain through its models and tables. What does this mean exactly? It helps to represent models within the domain and all of the data associated with it, including associations between those models (think many to many/has many/belongs to). It also assists in creating tables and classes, and easily allowing you to or alter them without the tedious work that SQL may have you do manually. Users can also utilize use rake, a popular task runner in Ruby that allows you to automate tasks, and it’s your right-hand-man when navigating Active Record. So remember creating tables manually in SQL? Or having to type out attr macros/initialize methods for your classes? Well, with proper AR association macros (we will get to that shortly), those will all be written for you.
While Active Record does complete a lot of the work for you, it’s still pivotal that you have the proper logic surrounding relationships between models within your domain planned out in order for it to function optimally. Which we will go over… now!
How do I set it up?
There are 4 main steps when creating an Active Record domain from scratch:
Ensure your environment is properly set up.
Here, you should ask yourself what your domain and models are going to be and what your attributes will be per model. Map this out and be sure about it. Those initial class models must be set up in order for us to create migrations for the tables to be persisted into your database. Set up your classes as normal (minus attr macros and initializers), but add < ActiveRecord::Base after setting up your class. An example:
With that being said, macros will look a little differently than they do in regular OOP. Instead of using attr readers, writers, and accessors, you will use has_many, belongs_to:, and has_many through (associations we should already be familiar with if you’ve dabbled with OOP before).
Creating and facilitating migrations.
Migrations can be a number of things, but in my experience we have mainly used it in order to create tables. Any time you want to create a new migration, you can easily do so by running the rake command
rake db:create_migration NAME=create_(tablenamehere) in your terminal. When setting up tables, there are a few conventions to remember. Models will remain capitalized (with camelcase if multiple words), and corresponding tables will be lowercase and pluralized. *If you’re unsure of what the plural/singular version of a word is, run this in your terminal! Once the migration is created, it will show up in your file with a series of numbers (a date and timestamp), and the name of your file. Here, you can begin migrating your new table into your database. I will post an example below. Once you have your table fully set up, run rake command rake db:migrate, and your table will be migrated into the database.
You are able to check the status of your migration with rake db:migrate:status, and you can also check the schema in your schema.rb file. It’s very important that you do not alter the schema directly, without “rolling back” the migration you have just made with rake db:rollback. For example, if you made a change two migrations ago, you need to rollback twice in order to make the proper changes. A few more conventions to remember: in AR, the main data types will be integers, strings, text, booleans, and real numbers. Those are initiated in the above code, along with their corresponding attributes. When creating migrations, it’s important that you are doing them one by one, creating the migration, filling it out with its attributes, checking the schema, and moving on to the next one.
Create seeds and use them to test.
Seeds are basically dummy data that we fill the seeds.rb file with in order to be able to test our data. How else will we know that it works? Having a thorough seed file is crucial to ensure that your methods are correct, and that all of your macros are set up correctly. You are able to test your methods in your console, and also
CRUD — let’s test it out.
CRUD is an acronym for create, read, update, and delete. It should go without saying that it’s important for you to be able to interact with your data. Creating new data could be running Music.new or Music.create to create new instances. Reading means that you are able to interact with and return specific instances within the models: Music.all, Music.first, etc. Updating essentially means that you are able to find and update a specific instance: Music.update. Lastly, deleting means that you are able to delete a single row or an entire table with either the .destroy or .destroy_all method.
…and there you have it! Hopefully this will be helpful in terms of getting you more comfortable with how to be able to navigate Active Record.
