DEV Community: Carisa Elam

Active Record Queries Cheat Sheet

Carisa Elam — Fri, 16 Aug 2024 23:29:48 +0000

Active Record allows you to execute SQL commands using Ruby. This guide cuts through the fluff to provide a simple reference for some common Active Record queries. For each query, you’ll find the SQL equivalent and a brief description of what it returns, making it easy to see how the methods map to SQL commands.

find

SQL Equivalent: SELECT * FROM model WHERE (model.id = :id)
Returns: the record with the specific ID.

take

SQL Equivalent: SELECT * FROM model LIMIT 1
Returns: the record without any ordering

first

SQL Equivalent: SELECT * FROM model ORDER BY model.id ASC LIMIT 1
Returns: the record with the first primary key that exists

last

SQL Equivalent: SELECT * FROM model ORDER BY model.id DESC LIMIT 1
Returns: the record with the last primary key that exists

find_by

SQL Equivalent: SELECT * FROM model WHERE (model.parameter = 'foo') LIMIT 1
Returns: the first record matching the condition

This is not meant to be an exhaustive guide.
For more information, see the Rails Guides: Active Record Query Interface.

👋Connect with me on Github or LinkedIn.
I'd love to hear your thoughts!

Beginner–Friendly Basics: Rails Migrations

Carisa Elam — Tue, 13 Aug 2024 20:03:16 +0000

If you are new to Rails, understanding migrations can feel overwhelming. This article covers the basics and simplifies some of the primary components of migration.

We'll use a super simple blog app deployed via Railway as an example throughout this article.

What is a Rails Migration?

Put simply, it is just a script that updates the schema of a database.

Each migration is like an updated version of your database.

When a Rails project is created, often one of the first things you need to do is to start creating a data model. In our case, a model for the articles that will populate the blog. Because this process involves the creation of a database table, you need to use migration to "change the schema" by setting up the table.

Rails migration commands are simple and plain English, but they translate into SQL queries and get the job done under the hood.

How Do You Perform a Migration?

Migrations can be triggered in a handful of different ways. We'll discuss the main two:

Generating a model

Generating a standalone migration

1. Generating a Model
No need to create all of the files and connections yourself, Rails handles most of the legwork for you.

For our blog example, running this command:

$ rails generate model Article

would return something like this:

$ rails generate model Article
      invoke  active_record
      create    db/migrate/20240812123456_create_articles.rb
      create    app/models/article.rb
      invoke    test_unit
      create      test/models/article_test.rb
      create      test/fixtures/articles.yml

Let's break that down.
invoke active_record: as it implies, this brings Active Record into the picture

create db/migrate/20240812123456_create_articles.rb: generates a migration file with a class named CreateArticles, which will ultimately create the articles table.

class CreateArticles < ActiveRecord::Migration[7.2]
  def change
    create_table :articles do |t|
      t.timestamps
    end
  end
end

create app/models/article.rb: creates your model

class Article < ApplicationRecord
end

...and the model creates concludes by generating some testing files.

2. Generating a standalone Migration
When you need to modify an existing data table or create a new schema change WITHOUT creating a new model, you can use the following command:

$ rails generate migration CreateArticle

which will output something like this instead:

$ rails generate migration CreateArticle
      invoke  active_record
      create    db/migrate/20240812123456_create_article.rb

As you can see, this command results in fewer things happening. Active Record is invoked, and an article migration file is created. rails generate migration does just what it says—it creates a migration file, not a model.

When would I need to use rails generate migration?

Adding or removing columns from existing database tables
Renaming a column or a table
Changing the data type of a column
Creating a join table
Deleting ('dropping') a table from the database

Am I done?
No.
At this point, our changes have not actually been applied to the database schema. To do that, you would run:

$ rails db:migrate

and voila! Your database table has been created, updated, deleted, etc.

How do I know the migration was successful?
Upon completion, the migration should output something like this to confirm success:

==  CreateArticles: migrating =================================================
-- create_table(:articles)
   -> 0.0030s
==  CreateArticles: migrated (0.0030s) ========================================

What if I mess up something?
Made a mistake? No problem. Migrations are typically reversible, and it's almost as easy as Ctrl–Z! You simply run
$ rails db:rollback and your migration effectively gets "undone." There's more to it than that under the hood, but as long as you have specified how each method should "reverse" itself, Rails handles the rest.

Do I need to reserve the first column for a primary key?
Typically, the first column in a table is reserved for the id, which serves as a unique identifier for each row of the table. By default, Rails automatically includes an auto-incrementing primary key id column to each table. So no need to do that yourself! You won't really "see" that anywhere in the code, you just have to hop on the Rails train and believe that it is happening behind the scenes.

What Else Can Migrations Do?

Migrations are used in a ton of processes within a Rails app. While this article covers just the basics, here are some other things you can do with migrations:

Create join tables
Change current tables
Change current columns
Add column modifiers (comment, default, limit, etc.)
Create foreign key columns to connect tables
Execute custom SQL commands (for when the built-in functions just aren't enough)

Summary

While we've just scratched the surface of what migrations can do, it's clear that Rails migrations can simplify the process of updating your database. Like Active Record, migrations are designed to be as user-friendly as possible for developers while all of the complexity is handled behind the scenes.

The result? We can get more done and focus on creating, not configuring.

Helpful Links

The Odin Project
Rails Active Record: Quick Start!
Rails Guide: Active Record Migrations

Image by freepik

👋Connect with me on Github or LinkedIn.
I'd love to hear your thoughts!

Rails Active Record: Quick Start!

Carisa Elam — Mon, 12 Aug 2024 21:04:56 +0000

👋 Hello fellow learner!

As I dive into Rails for the first time with the Odin Project, I’m learning just how cool (and a bit confusing) Active Record can be. I decided to write this post to help my future self remember the basics and to share what I’ve learned with others. Think of it as a quick reference to getting started with Active Record without the fuss. It highlights a few elements of Active Record that I thought were particularly important.

Hope this helps clear things up and makes your Rails journey a bit smoother!

What is Active Record?

Active Record is the part of Rails that handles the database and connects it to your application. Creating tables, altering schemas, and formulating queries requires a certain level of complexity and a lot of configuration code. Rails handles all of that for us with Active Record and simplifies the process of interacting with our database. It is almost like a translator between Ruby and basically any database language.

What does Active Record do?

Takes the app data from the rows and columns in your database

Allows you to interact with the data as a Ruby object

It is like magic!—like a little middleman between you and your database that handles writing and executing all of the queries you would otherwise have to type out yourself. Instead, you provide it with something written in Ruby (which is much easier to write, read, and understand, IMHO), and it translates that into the language of your database and returns the result you're looking for.

So how does Active Record know what kind of database you are using?
You basically give Active Record some basic information about your database via the config/database.yml file, and it handles the rest. That means if you end up switching databases later on, you should theoretically only have to change the configuration info. Is this what they mean by 🚃 The Rails Way 🚃?

It seems pretty nice honestly...

How does this look on a Rails app?
We'll use a super simple blog app deployed via Railway as an example.

Information about the articles on the blog are stored in a database table called articles. The model used to access that data is called article, in keeping with the Rails singular/plural configuration.

The model is simply a Ruby object...

class Article < ApplicationRecord
  ...
end

...that inherits from ApplicationRecord which in turn inherits from ActiveRecord.

class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class
end

So there's the connection! And it is easy to see thanks to Ruby.

Naming conventions

This isn't just to make your code look pretty. Rails emphasizes "convention over configuration" to help lighten the load on developers. Instead of having to write out lots of lines of configuration code to get your application to work, just hop onboard the Rails wagon 🚃 and do it like they say to.

Rails will automatically pluralize your model's class names. In our case, the model was class Article, so the database table is called articles as you can see in our articles controller:

class ArticlesController < ApplicationController
 def index
    @articles = Article.all
  end

  def show
    @article = Article.find(params[:id])
  end

  # etc...
end

Rails uses the Active Support library to accomplish this. So it is not magic, nor is it simply adding an 's' on at the end. (e.g., Person gets mapped to people automatically.)

Creating an Active Record model

When you create a new Rails app and generate your first model, the ApplicationRecord class is created and placed in the app/models directory. As we saw before, ApplicationRecord inherits from ActiveRecord::Base. So to create a new Active Record model, you just create a new class that inherits from Application Record. Remember to make your class name singular!

class Article < ApplicationRecord
end

When you do this, Rails creates a Article model that is mapped to a articles table in the database. Each column of the table will be mapped to an attribute of the Article class. An instance of the Article class represents a single row in the articles database table.

But where is the table? Is it created already?
Rather than creating the table via a CREATE TABLE SQL statement that explicitly defines all of the column headers and their types, you just use an Active Record migration on the command line.

$ bin/rails generate migration CreateArticles title:string body:text

class CreateArticles < ActiveRecord::Migration[7.2]
  def change
    create_table :articles do |t|
      t.string :title
      t.text :body

      t.timestamps
    end
  end
end

$ bin/rails db:migrate

Another example of hopping on the Rails wagon 🚃 and letting it do its thing.

CRUD and Active Record

Rails is built around the idea that most applications operate on data in four ways: Creating, Reading, Updating, and Deleting (CRUD). This is so ingrained in Rails that when you create a new Active Record, Rails automatically provides a set of built-in methods to make it super easy to perform CRUD operations.

Each of these methods results in the creation and execution of SQL statements behind the scenes. Rails also provides plain English ways of accessing these methods, making it even easier to connect with your records. 🚃 Hop Aboard!

What you see: articles = Article.all

What goes on behind the scenes: SELECT "articles".* FROM "articles"

Summary

Active Record is a fantastic tool, though it can be confusing when you're first learning it. But the takeaway is that Active Record handles a lot of the heavy lifting, syntax, and configuration, allowing us to interact with our database via Ruby objects. When in doubt, hop on board the Ruby wagon 🚃 and let Active Record do what it is meant to do: make our lives easier as developers.

Helpful Links

The Odin Project
Rails Guides: Active Record Basics

Photo by Sash Bo on Unsplash

👋Connect with me on Github or LinkedIn.
I'd love to hear your thoughts!