Active Record Basics

🗄️ Active Record Basics

🏗️ Migrations — Versioned Schema Changes

Copy$ rails generate migration CreatePosts title:string body:text published:boolean

Copy# db/migrate/20260101000000_create_posts.rb
class CreatePosts < ActiveRecord::Migration[7.1]
  def change
    create_table :posts do |t|
      t.string  :title
      t.text    :body
      t.boolean :published, default: false
      t.timestamps   # adds created_at and updated_at automatically
    end
  end
end

$ rails db:migrate

A migration is a single, ordered, timestamped Ruby file describing one schema change — running rails db:migrate applies every migration that hasn't run yet, in order. This is the direct Rails equivalent of manually writing and tracking CREATE TABLE/ALTER TABLE SQL yourself against a mysql2 connection, with the ordering and "has this already run?" bookkeeping handled automatically instead of by convention you maintain yourself.

📋 schema.rb — The Combined Snapshot

Copy# db/schema.rb (auto-generated, never edited by hand)
ActiveRecord::Schema[7.1].define(version: 2026_01_01_000000) do
  create_table "posts" do |t|
    t.string  "title"
    t.text    "body"
    t.boolean "published", default: false
    t.datetime "created_at"
    t.datetime "updated_at"
  end
end

schema.rb is automatically regenerated after every migration — a single, current source of truth for the entire database structure. Express has no direct equivalent at all; without a separate schema-tracking tool, the actual structure of a mysql2-backed database lives only in the database itself, discoverable only by connecting and inspecting it directly.

🎭 Models — Almost Suspiciously Empty

Copy# app/models/post.rb
class Post < ApplicationRecord
end

🔧 Basic CRUD — Active Record vs Raw SQL

⛓️ Chained Query Methods

CopyPost.where(published: true)
    .order(created_at: :desc)
    .limit(5)

Each method returns another chainable query object rather than immediately hitting the database — the actual SQL query is only built and executed once the result is enumerated (printed, looped over, etc.). This reads close to a plain-English sentence — "posts that are published, ordered by newest, limited to five" — and generates a single, efficient SQL query behind the scenes, comparable to method chaining Enumerable chains from both Ruby courses, just building SQL instead of transforming an in-memory array.

🛡️ Automatic SQL Injection Protection

Copy# SAFE -- parameterized automatically
Post.where(title: params[:title])

# SAFE -- ? is a placeholder, Active Record escapes the value
Post.where("title = ?", params[:title])

# DANGEROUS -- raw string interpolation, exactly the vulnerability from the SQLi course
Post.where("title = '#{params[:title]}'")

Every one of Active Record's normal query methods — where with a hash, find, create — parameterizes values automatically, the same protection the completed SQL Injection course covered as essential. The dangerous pattern above is the exact same mistake covered there: building a query with raw string interpolation instead of a placeholder, whether in mysql2 or, as shown, even inside Active Record's own string-based where form if used carelessly.

📜 Data Access, Side by Side

💻 Coding Challenges

🎯 What's Next

Next chapter: Active Record Associations — has_many, belongs_to, and how Rails handles relationships between tables that would otherwise require manually writing JOIN queries.