ActiveRecord, Standalone
Migrations, and aRel
Alex Tironati
Overview
● Part 1 - ActiveRecord/Standalone Migrations
○ The Problem
○ Motivation
○ The Solution
○ Implementation
● Part 2 - Arel vs. AR
○ ActiveRecord Basics
○ ARel tables
○ Select and Join queries
○ Using a QueryBuilder
○ Bringing it home
Part 1
Standalone Database Migrations
in non-Rails Projects
The Problem
The Underlying Problem
● We have no process in place for managing
the database schemas for our Java projects
● This is the best
we could do
before:
Is that good enough?
Motivation
● We should be able to keep track of the schema
changes over time
● We should have a standard way to change the schema
across all databases
● We shouldn’t have to go through SQLPro to make those
changes
● We should have an easy way to recreate the current
schema from scratch
● We should be able to run those changes automatically,
after they are defined
What magical wonder-framework of Poseidon does all
this shit?
?
Oh that’s right
Implementation
● Add a .env file
● Make a project-level db folder
● Create a Gemfile and add:
○ gem 'active_record_migrations'
○ gem 'mysql2'
○ gem 'dotenv'
● Create a migration file for each table in your database:
○ rake db:new_migration name='create_note_tables'
○ Remember to include index definitions
○ Make sure all of the fields match your current schema exactly
○ run ‘rake db:migrate’ to test a lot locally
● When the migrations are written, go to new schema_migrations table
Implementation
● Create schema_migrations on staging and prod instances
● Duplicate entries (timestamps) from local schema_migrations table to
remote instances so that they match (the migrations are in order)
● run migrations on remote instance:
○ rake db:migrate RAILS_ENV=staging
● This will generate a file in db/schema.rb
○ Be sure to commit and push this to Github every time you run
migrations
● Update your Capistrano build to automatically run migrations for the
right environment on deploy
.env
Migration Example
Ugly way to make bigint primary key
Schema.rb
Capistrano task
Part 2
ActiveRecord vs. aRel
RailsConf 2014 - Advanced aRel: When
ActiveRecord Just Isn’t Enough
● Cameron Dutro
● Works on Twitter’s International
Engineering team
● https://www.youtube.com/watch?
v=ShPAxNcLm3o&index=14&list=PLE7tQUdR
KcyZ5jfnbS_osIoWzK_FrwKz5
Rails using SQL
Rails ¾ Improvements
Issues
● Just wrapping SQL in Rails methods
● You have to know underlying language
● No syntax checking
● Who likes matching question marks?
○ They’re confusing, man
● Not object-oriented
Arelized
Benefits
● Don’t have to know SQL
● Ruby syntax checking
● Chainable, composable
● No question marks
● Easier to read
ActiveRecord
● Database abstraction
● Persistence layer
○ Database rows as Ruby objects
● Domain Logic
○ Validations
● Associations
Arel
● “Relational Algebra” for Ruby
● Used to build queries,
generates ASTs
● Applies query optimizations
● Enables Chaining (subtrees)
● Not well documented
● Knows nothing about models or database, does not retrieve
data
○ That’s ActiveRecord’s job
○ Arel is all like “IDGAF” about yo models, db, or data
What’s an AST?
Arel Table
Arel-Helpers Gem
● gem install arel-helpers
Active Record Relations and .to_sql
Arelized
Select
More ActiveRecord vs. Arel
In this
case AR
is better/
cleaner
.not_eq(nil)
Reminder of the Data Model
Joins
Outer Joins Only Possible in Arel
Ugly Arel Version
Outer Joins Only Possible in Arel
Query Builder/Builder Pattern
Constructing a Query - Post Query Bldr
Constructing a Query cont.
Example in our own code!
Translated to SQL
The End

Active record, standalone migrations, and working with Arel