ActiveRecord 2.3

ActiveRecord 2.3
Reuven M. Lerner
October 20th, 2010
1Monday, October 25, 2010

What is a database?
Database
Store data
conﬁdently
Retrieve data
ﬂexibly

Relational databases
Deﬁne tables,
store data in them
Database
Retrieve data from
related tables

Database
communication
SQL goes here
CREATE TABLE
INSERT
UPDATE
DELETE
Database

SQL is great! But...
• It adds a second language to existing Ruby
• It’s a totally different paradigm
• We want to work with Ruby objects!
• Incidentally, SQL-in-something-else was
the paradigm for years...

Solution: ORM (object-
relational mapper)
ORM
Ruby
Database

relational mapper)
ORM
Ruby
Database
Write in Ruby

relational mapper)
ORM
Ruby
Database
Write in Ruby
ORM translates to SQL,
sends to database

relational mapper)
ORM
Ruby
Database
Write in Ruby
sends to database
Results go
to ORM

relational mapper)
ORM
Ruby
Database
Write in Ruby
sends to database
Results go
to ORM
ORM turns results
into Ruby objects

ActiveRecord
• By far, the most popular ORM for Ruby
• Not the only one — e.g., DataMapper
• We work with objects whenever possible
• We deﬁne as little as possible
• Our objects act as intelligent
representations of what’s in the database

ActiveRecord and Rails
• The idea of ActiveRecord preceded Rails
• Mark Fowler, from Thoughtworks (and
the “Refactoring” book)
• You can use ActiveRecord without Rails
• ActiveRecord was written for Rails
• And let’s face it — nearly everyone uses
ActiveRecord within Rails applications

Opinionated!
• ActiveRecord has some ideas about how
your application should work
• If you work in the same way, the work is
both easy and fun
• If you try to work in a different way, it’ll be
very difﬁcult and frustrating
• “Syntactic vinegar”

Using ActiveRecord
• Typically, we subclass ActiveRecord::Base in
each of our model ﬁles
• That is, all of the classes deﬁned in app/
models/*.rb
• You don’t have to inherit from
ActiveRecord::Base, of course! You can
even mix and match with different
models

Version warning!
• Everything that I’m about to show is for
Rails 2.3.8
• That’s the version we’re using here
• But the latest ofﬁcial release is 3.0, and
much online documentation will reﬂect that
• So when you look online, check the
version number!

Person model
class Person < ActiveRecord::Base
end

Person model
end
Singular class name

Person model
end
Singular class name Standard parent class

We can already start!
~/Downloads/foo$ ./script/console
Loading development environment
(Rails 2.3.8)
>> Person
=> Person(Table doesn't exist)

Object ≠ Table
• The object exists, but the table doesn’t.
• So let’s create the table!

Non-Rails approach
• Create the table
• Keep the definition in a file
• Tell everyone that you’ve created the table
• When you make changes to the table,
update the file and tell everyone again
• Hope that your changes don’t clash!

Migrations
• Ruby program that describes how to
change the database schema
• Add tables
• Rename columns
• Remove columns
• Set defaults

Platform independent
• Because migrations are written in Ruby,
they’re platform independent
• Well, mostly...
• ... they tend to use MySQL ideas and
semantics
• No foreign keys, for example
• Works well enough with most databases

Create a migration
./script/generate migration
create_person
./script/generate model person
./script/generate model person
first_name:string
last_name:string email:string

The migration ﬁle
• Migrations are in db/migrate
• Each has a unique ﬁlename, and a
timestamp
• (The odds of two developers creating
migrations at the same second, and with
the same name, are slim)

class CreatePeople < ActiveRecord::Migration
def self.up
create_table :people do |t|
t.string :first_name
t.string :last_name
t.string :email
t.timestamps
end
end
def self.down
drop_table :people
end
end

def self.up
t.string :last_name
t.string :email
t.timestamps
end
end
def self.down
drop_table :people
end
end
Migrate forward

def self.up
t.string :last_name
t.string :email
t.timestamps
end
end
def self.down
drop_table :people
end
end
Migrate forward
Migrate backward

def self.up
t.string :last_name
t.string :email
t.timestamps
end
end
def self.down
drop_table :people
end
end
Migrate forward
Migrate backward
Data types

def self.up
t.string :last_name
t.string :email
t.timestamps
end
end
def self.down
drop_table :people
end
end
Migrate forward
Migrate backward
Data types
Block!

Run the migration
• To run all pending migrations:
rake db:migrate
• To run the “down” method until we get to a
certain migration:
rake db:migrate
VERSION=20101013095549

Changing migrations
• Changing the migration ﬁle is OK!
• Add indexes, defaults, etc.
• But don’t change a table structure by
editing a migration
• Rather, create a new migration that adds/
renames/deletes the column
• Migrations are additive (and addictive)

rake db:migrate
• A table, schema_migrations, is automatically
created in the database
• It has one column,“version”, which contains
one row for each run migration
• When you run db:migrate, it runs all of the
migrations that are not in the table
• This allows for merges between developers

Migrations and models
• Column names and types are deﬁned in the
database, not in the model
• This means that column names and types
are set in the migrations
• The easiest way to ﬁnd out what columns
are in an ActiveRecord model class?
• The console, of course!

Migrating
~/Downloads/foo$ rake db:migrate
(in /Users/reuven/Downloads/foo)
== CreatePeople: migrating
===================================================
-- create_table(:people)
-> 0.2094s
== CreatePeople: migrated (0.2097s)
==========================================

Migrating
== CreatePeople: migrating
===================================================
-- create_table(:people)
-> 0.2094s
== CreatePeople: migrated (0.2097s)
==========================================
We’re up to date,
so nothing happens

Let’s check again
>> Person
=> Person(id: integer,
first_name: string, last_name:
string, email: string,
created_at: datetime,
updated_at: datetime)

Let’s check again
>> Person
Hey, where did “id”
come from?

Let’s check again
>> Person
Hey, where did “id”
come from?
And what
about these?

Assumptions
• Convention over conﬁguration!
• Tables are plural, classes are singular
• class “Person”, but table “People”
• Primary key is always called “id”
• created_at, updated_at are set
automatically by ActiveRecord upon
creation or update to the record

Wait! Where’s the DB?
• When did we tell Rails how to connect to
the database?
• Look in conﬁg/database.yml
• The only conﬁguration you need
• It tells ActiveRecord what database you
have, and how to connect...
• ... for each environment

development:
adapter: postgresql
encoding: unicode
database: foo_development
pool: 5
username: reuven
password: reuven

Wait, that’s it?
• Well, mostly.
• There are additional (optimal) parameters
• And some configuration is done in the
environment config files
• We’ll ignore these for now

Console reloading
• If you use the console (and you should!)
then modifying ActiveRecord models may
cause issues
• Use “reload!” to reload the environment
• You’ll then need to re-create all objects
• Better than having invalid objects...

How many records?
?> Person.count
=> 0

OK, we’ll add one
>> p = Person.new
=> #<Person id: nil, first_name: nil, last_name:
nil, email: nil, created_at: nil, updated_at: nil>
>> p.save!
=> true
>> Person.count
=> 1

Wait a second!
• That person record we just created is
pretty useless.
• We really don’t want nameless people in
our database.
• We could (and should!) update the
database deﬁnition with a new migration
• But we’ll ignore that for now. Don’t tell!

Better creation
• The “new” method creates a new object,
but doesn’t save it to the database
• This is why it has nil for an ID
• After you save, it has an ID
• To create an object and save it right away,
use the “create” method instead
• Both “new” and “create” return the object

save! and create!
• save returns true or false
• create returns the object or false
• save! and create! are the same as their
“quiet” counterparts upon success
• But raise an exception if there is a problem

Missing attributes?
• If you fail to set an attribute, then Ruby will
pass it nil
• However, if you have a default value set in
the database, then it’ll get that
• Don’t set created_at and updated_at; those
are set automatically

The Java way
>> p = Person.new
=> #<Person id: nil, first_name: nil,
last_name: nil, email: nil, created_at: nil,
updated_at: nil>
>> p.first_name = 'Reuven'
=> "Reuven"
>> p.last_name = 'Lerner'
=> "Lerner"
>> p.email = 'reuven@lerner.co.il'
=> "reuven@lerner.co.il"
>> p.save!
=> true

The Ruby way
>> p = Person.new(:first_name =>
'Reuven', :last_name =>
'Lerner', :email =>
'reuven@lerner.co.il')
=> #<Person id: nil, first_name:
"Reuven", last_name: "Lerner",
email: "reuven@lerner.co.il",
created_at: nil, updated_at: nil>

The Ruby way
'Reuven', :last_name =>
'Lerner', :email =>
'reuven@lerner.co.il')
=> #<Person id: nil, first_name:
Hash of name-
value pairs

It’s not a free-for-all
>> p10 = Person.new(:eye_color => 'brown')
ActiveRecord::UnknownAttributeError: unknown attribute: eye_color
from /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.3.8/
lib/active_record/base.rb:2906:in àssign_attributes'
lib/active_record/base.rb:2902:in èach'
lib/active_record/base.rb:2902:in àssign_attributes'
lib/active_record/base.rb:2775:in àttributes='
lib/active_record/base.rb:2473:in ìnitialize'
from (irb):44:in `new'
from (irb):44
>>

Updating ﬁelds
>> p.first_name = 'Bibi'
=> "Bibi"
>> p.save
=> true

Updating ﬁelds
=> "Bibi"
>> p.save
=> true
If you don’t save the object,
then you haven’t changed it
in the database!

update_attributes
• It’s easier and safer to update both the
object and the database simultaneously
>> p.update_attributes(
:first_name => 'Bibi')
=> true

Multiple attributes
• p.update_attributes(
:first_name => 'Bibi',
:last_name => 'Netanyahu')

Avoid this!
• update_attribute
• singular (not plural)
• takes two params (attribute, value),
rather than a hash
• doesn’t go through any Rails validators!
• From my perspective, this method is
dangerous, and should be avoided

By the way...
• Remember our model ﬁle?
• It’s still empty.
• And yet, it allows us to create, save, and
update models naturally and easily.
• Pretty cool, eh?

Semi-protection
• attr_protected :ﬁrst_name
• ﬁrst_name cannot be changed with
update_attributes, but it can be updated
with a setter or update_attribute
• attr_accessible: Lists those attributes that
are not protected
attr_accessible :email, :zip_code

ﬁnd
• This is the workhorse of ActiveRecord
• The “ﬁnd” method is really a lot of different
methods with a single interface

ﬁnd by ID
Person.find(3)
• If there is a Person object with ID = 3, that
one object is returned
• If no object exists, an exception is raised
• Yes, this is annoying
Person.find(2, 6) # returns array

Get them all!
Person.find(:all)
Person.all # same thing

One object or many?
• Simple ﬁnd with an ID — one object (or
raises an exception)
• ﬁnd with multiple IDs — returns an array
of objects, or an exception if even one ID
doesn’t exist
• all — always returns an array, and perhaps
even an empty array

Conditions
• We can add conditions
• turned into WHERE clause in SQL
• You’ll almost always want conditions

Conditions, Ruby style
>> Person.all(:conditions => {:first_name =>
'foo'})
=> []
'Reuven'})
=> [#<Person id: 6, first_name: "Reuven",
last_name: "Lerner", email:
"reuven@lerner.co.il", created_at: "2010-10-13
18:01:03", updated_at: "2010-10-13 18:01:03">,
#<Person id: 7, first_name: "Reuven", last_name:
"Lerner", email: "reuven@lerner.co.il",
created_at: "2010-10-13 18:04:09", updated_at:
"2010-10-14 06:32:19">]

Conditions, Ruby style
'foo'})
=> []
'Reuven'})
18:01:03", updated_at: "2010-10-13 18:01:03">,
"2010-10-14 06:32:19">]
Hash

Conditions, SQL style
>> Person.all(:conditions => "first_name =
'Reuven'")
18:01:03", updated_at: "2010-10-13 18:01:03">,
#<Person id: 7, first_name: "Reuven",
18:04:09", updated_at: "2010-10-14 06:32:19">]

'Reuven'")
18:01:03", updated_at: "2010-10-13 18:01:03">,
18:04:09", updated_at: "2010-10-14 06:32:19">]
String

>> Person.all(:conditions => "first_name = '#
{@person.first_name}'")
18:01:03", updated_at: "2010-10-13 18:01:03">,
18:04:09", updated_at: "2010-10-14 06:32:19">]

18:01:03", updated_at: "2010-10-13 18:01:03">,
18:04:09", updated_at: "2010-10-14 06:32:19">]
Variable

Don’t do this!
• SQL injection attacks can happen
• There’s no reason for it
• If someone hands you a string containing a
quote mark and then some SQL, it could be
executed if you’re not careful
• Injection attacks should no longer occur!
• (This was true as far back as 1996...)

XKCD

Sweden, last month

Interpolating
parameters
• Instead of:
• Use:
>> Person.all(:conditions => ["first_name = ?",
@person.first_name])

Interpolating
parameters
• Instead of:
• Use:
Array of strings

Interpolating
parameters
• Instead of:
• Use:
Question mark
Array of strings

Interpolating
parameters
• Instead of:
• Use:
Question mark
No quotes!
Array of strings

Ordering results
• Remember:A relational database doesn’t
store its rows in any order
• If you don’t specify an order, you will
almost certainly be surprised

Ascending order
'Reuven'", :order => 'created_at')
"reuven@lerner.co.il", created_at:
"2010-10-13 18:01:03", updated_at:
"2010-10-13 18:01:03">, #<Person id: 7,
first_name: "Reuven", last_name: "Lerner",
email: "reuven@lerner.co.il", created_at:
"2010-10-13 18:04:09", updated_at:
"2010-10-14 06:32:19">]

Descending order
'Reuven'", :order => 'created_at DESC')
"2010-10-13 18:04:09", updated_at:
"2010-10-14 06:32:19">, #<Person id: 6,
first_name: "Reuven", last_name: "Lerner",
email: "reuven@lerner.co.il", created_at:
"2010-10-13 18:01:03", updated_at:
"2010-10-13 18:01:03">]

Combining
>> Person.all(:order => 'last_name ASC,
created_at DESC')
18:04:09", updated_at: "2010-10-14 06:32:19">,
"2010-10-13 18:01:03">, ...

Where to order?
• The database is almost certainly faster at
ordering
• So invoking #all and then #sort is probably
not a good idea
• In fact, the database is generally faster at
ﬁltering, too — so conditions are better
than #all and #select

ﬁrst
• Returns the ﬁrst row (object) from the
database — or nil, if none was found
Person.first
• Of course, without an order, you don’t know
which row you’ll get!
Person.first(:order =>
'created_at')

Transforming results
• Person.all returns an array — so you can
invoke whatever you want on that array!
• Get an array of last names:
Person.all.map {|p|
p.last_name}

Iterate over results
Person.all.each {|p| puts
p.inspect}
Person.all.each {|p|
p.update_attributes(:admin =>
false)}

Dynamic finders
• Remember method_missing? ActiveRecord
uses this to provide “dynamic finders” —
versions of find that can make our code
more readable
• If you have a row named xxx, you can say
find_by_xxx or find_all_by_xxx

ﬁnd_by_ﬁrst_name
>> Person.find_by_first_name('Reuven')
=> #<Person id: 6, first_name: "Reuven", last_name:
"Lerner", email: "reuven@lerner.co.il", created_at:
"2010-10-13 18:01:03", updated_at: "2010-10-13
18:01:03">
>> Person.find_all_by_first_name('Reuven')
=> [#<Person id: 6, first_name: "Reuven", last_name:
"2010-10-13 18:01:03", updated_at: "2010-10-13
18:01:03">, #<Person id: 7, first_name: "Reuven",
last_name: "Lerner", email: "reuven@lerner.co.il",
"2010-10-14 06:32:19">]

"2010-10-13 18:01:03", updated_at: "2010-10-13
18:01:03">
"2010-10-13 18:01:03", updated_at: "2010-10-13
"2010-10-14 06:32:19">]
Many ﬁnd this
easier to read

"2010-10-13 18:01:03", updated_at: "2010-10-13
18:01:03">
"2010-10-13 18:01:03", updated_at: "2010-10-13
"2010-10-14 06:32:19">]
Many ﬁnd this
easier to read
Add “all” to
get an array

Negative results
>> Person.find_by_first_name('blah')
=> nil
>> Person.find_all_by_first_name
('blah')
=> []

Negative results
>> Person.find_by_first_name('blah')
=> nil
>> Person.find_all_by_first_name
('blah')
=> []
No exception!

Multiple attributes
>> Person.find_by_first_name_and_last_name
('Reuven', 'Lerner')
=> #<Person id: 6, first_name: "Reuven",
"2010-10-13 18:01:03", updated_at:
"2010-10-13 18:01:03">

find_or_create_by_...
• Use a dynamic finder... and if you don’t find
a result, then create a new object
• If the object fails validations, return a new
(unsaved) object
Person.find_or_create_by_first_name
('Reuven');
Person.find_or_create_by_first_name
('Reuven', last_name => 'Lerner');

Caching
• ActiveRecord caches results on a per-
session basis
• So if you have already retrieved an object
with the current request, it’ll be cached for
further retrievals
• This doesn’t happen across requests,
though

Look in the log!
• In the development environment, you’ll see
your queries rewritten using SQL.
• This is a great way to see what is happening
in the underlying database

Associations
• ActiveRecord really shines when it comes
to “associations”
• The object equivalent of primary/foreign
keys connecting database tables

Pets!
• Let’s make it possible for people to have pets
./script/generate model pet
animal_type:string name:string
person_id:integer
rake db:migrate

Pets!
• Let’s make it possible for people to have pets
./script/generate model pet
animal_type:string name:string
person_id:integer
rake db:migrateEach pet belongs
to one person

belongs_to
• Declaration (aka a class method) in the
model ﬁle
• Meaning:There is a foreign key pointing
from self to another object, via its ID
• The name of the foreign key is (by default)
the other object’s name (singular) with _id

Change Pet.rb
class Pet < ActiveRecord::Base
belongs_to :person
end

What does this do?
• Doesn’t create the foreign key in the DB
• Doesn’t set the foreign key
• Doesn’t enforce anything
• It does, however, deﬁne a bunch of methods
that we can now use on a pet

Creating a pet
>> spot = Pet.new(:animal_type =>
'dog', :name => 'Spot', :person_id =>
Person.first.id)
=> #<Pet id: nil, animal_type: "dog", name:
"Spot", person_id: 6, created_at: nil,
updated_at: nil>
'dog', :name => 'Spot', :person =>
Person.first)
updated_at: nil>

Creating a pet
Person.first.id)
updated_at: nil>
Person.first)
updated_at: nil>
Here we use the ID

Creating a pet
Person.first.id)
updated_at: nil>
Person.first)
updated_at: nil>
Here we use the ID
Here we use the object

New “person” method!
>> spot.person
=> #<Person id: 6, first_name:
created_at: "2010-10-13
18:01:03", updated_at:
"2010-10-13 18:01:03">

Pet e-mail (p-mail?)
• Pets use their owner’s e-mail address
• One way is to deﬁne a new method on
Pet.rb
• Every instance of a pet will now respond to
the “email” method, and return the owner’s
e-mail address

With our email method
belongs_to :person
def email
person.email
end
end

Easier: Delegation!
belongs_to :person
delegate :email, :to => :person
end

By the way...
>> rover = Pet.new
=> #<Pet id: nil, animal_type: nil, name:
nil, person_id: nil, created_at: nil,
updated_at: nil>
>> rover.email
RuntimeError: email delegated to
person.email, but person is nil: #<Pet id:
nil, animal_type: nil, name: nil,
person_id: nil, created_at: nil,
updated_at: nil>

By the way...
>> rover = Pet.new
=> #<Pet id: nil, animal_type: nil, name:
nil, person_id: nil, created_at: nil,
updated_at: nil>
>> rover.email
RuntimeError: email delegated to
person.email, but person is nil: #<Pet id:
nil, animal_type: nil, name: nil,
person_id: nil, created_at: nil,
updated_at: nil>We can’t delegate to nil!

Avoid nil problems
belongs_to :person
delegate :email, :to => :person,
:allow_nil => true
end

Problem solved
>> rover = Pet.new
=> #<Pet id: nil, animal_type: nil,
name: nil, person_id: nil,
>> rover.email
=> nil

The other side
• So far, pets know about their owners...
• ... but owners don’t know about their pets
>> spot.person.pets
NoMethodError: undefined method `pets' for
#<ActiveRecord::Associations::BelongsToAssociation:
0x1089bba50>

one-to-one: has_one
If each person can have one pet, then we
could change person.rb to read:
has_one :pet
end

Using has_one
>> p = Person.first
"2010-10-13 18:01:03", updated_at:
"2010-10-13 18:01:03">
>> p.pet
=> #<Pet id: 1, animal_type: "dog", name:
"Spot", person_id: 6, created_at: "2010-10-14
07:43:59", updated_at: "2010-10-14 07:43:59">

Using has_one
>> p = Person.first
"2010-10-13 18:01:03", updated_at:
"2010-10-13 18:01:03">
>> p.pet
=> #<Pet id: 1, animal_type: "dog", name:
07:43:59", updated_at: "2010-10-14 07:43:59">
Each person has a pet

How does Rails do it?
• It does what we would do manually — looks
for all pets with our primary key value
Pet Load (1.2ms) SELECT *
FROM "pets" WHERE
("pets".person_id = 6) LIMIT 1

has_many
• More interesting, and trickier, is has_many
• Perhaps we have many pets!
has_many :pets
end

has_many
• More interesting, and trickier, is has_many
• Perhaps we have many pets!
has_many :pets
end Notice plural!

has_many
• With a has_many relationship in place, we
get a method (plural!) for pets
• It always returns an array (perhaps empty)
>> p.pets
=> [#<Pet id: 1, animal_type: "dog",
name: "Spot", person_id: 6,
created_at: "2010-10-14 07:43:59",
updated_at: "2010-10-14 07:43:59">]

Adding
>> p.pets
=> []
>> p.pets << Pet.new(:animal_type =>
'fish', :name => "Charlie")
=> [#<Pet id: 2, animal_type: "fish",
name: "Charlie", person_id: 7, created_at:
"2010-10-14 09:21:41", updated_at:
"2010-10-14 09:21:41">]
>> Pet.count
=> 2

Adding
>> p.pets
=> []
"2010-10-14 09:21:41", updated_at:
"2010-10-14 09:21:41">]
>> Pet.count
=> 2
Even though we used “new”,
the object was saved

Adding
>> p.pets
=> []
"2010-10-14 09:21:41", updated_at:
"2010-10-14 09:21:41">]
>> Pet.count
=> 2
Even though we used “new”,
the object was saved
Automatically used
our person

Array fun
>> Person.first.pets.select {|p|
p.animal_type == 'fish'}
=> []
>> Person.first.pets.select {|p|
p.animal_type == 'dog'}
=> [#<Pet id: 1, animal_type: "dog", name:
"Spot", person_id: 6, created_at:
"2010-10-14 07:43:59", updated_at:
"2010-10-14 07:43:59">]

many-to-many
• What if each person can have multiple
pets, and each pet can have multiple
owners?
• For that, we need a “join” table

Join table
People
Person
-Pets
Pets
foreign keys:
person_id
pet_id

Migration
./script/generate model
person_pet person_id:integer
pet_id:integer

person_pet.rb
class PersonPet < ActiveRecord::Base
belongs_to :person
belongs_to :pet
end

Update person.rb
has_many :person_pets
has_many :pets, :through => :person_pets
end

Update person.rb
has_many :pets, :through => :person_pets
end has_many :through
connects our models
via the join table

Update pet.rb
has_many :people, :through => :person_pets
end

Now it all works!
>> spot.people
=> []
>> spot.people << Person.first
18:01:03", updated_at: "2010-10-13 18:01:03">]
>> spot.people
18:01:03", updated_at: "2010-10-13 18:01:03">]

From the other side...
>> Person.first.pets
=> [#<Pet id: 1, animal_type: "dog", name:
07:43:59", updated_at: "2010-10-14 07:43:59">]

Join model
• It’s a full ActiveRecord model
• You can hang other attributes on it, if you
want
• However, it’s often there just for use as a
connection, with no day-to-day direct use

Association options
• has_many, belongs_to, and has_one all take
a bunch of options
• Some of them are to handle ActiveRecord
naming conventions
• Others can really help to shrink your code,
making your models more powerful and
expressive

Example: Order
• Perhaps you always want to list pets in the
order that they were created:
has_many :pets, :order =>
'created_at'
• Person.ﬁrst.pets will get the pets in order
• This is what we mean by pushing logic from
the controller into the model

Example:Auto-destroy
has_many :person_pets, :dependent
=> :destroy
has_many :pets, :through
=> :person_pets
end

Example:Auto-destroy
has_many :person_pets, :dependent
=> :destroy
has_many :pets, :through
=> :person_pets
end
When we delete a person,
we’ll also destroy the join
model person_pet

delete vs. destroy
• There are two ways to destroy an object
p.destroy
p.delete
• Both delete the row in the database
• Both freeze the object, so that we cannot
change it

delete vs. destroy
• But:
• destroy runs before_destroy and
after_destroy callbacks
• destroy handles dependent association
options (i.e., you can set it such that
dependent objects are deleted)
• So... use destroy, and not delete, OK?

Validations
• “Validations” are the ActiveRecord way to
ensure that your data is valid
• You can get around them!
• So these shouldn’t come in place of
constraints and checks in the database
• When you save or update a model, the
validations are checked and must pass

Built-in validations
• Rails comes with a large number of
validations
• declarations (i.e., class methods) put into
the ActiveRecord class
• Use as many of these as you want

validates_presence_of
• Let’s ensure that every person has ﬁrst and
last names:
validates_presence_of :first_name
validates_presence_of :last_name
end

Or, on a single line
validates_presence_of :first_name, :last_name
end
• I prefer the multi-line version, for easier
adding and removing of validations

So, what now?
>> p = Person.new
last_name: nil, email: nil,
>> p.save!
ActiveRecord::RecordInvalid:
Validation failed: First name can't
be blank, Last name can't be blank

So, what now?
>> p = Person.new
last_name: nil, email: nil,
>> p.save!
ActiveRecord::RecordInvalid:
Validation failed: First name can't
be blank, Last name can't be blank
Each violation
is listed

What errors occurred?
>> p.errors
=> #<ActiveRecord::Errors:0x1085d1020 @base=#<Person id: nil,
first_name: nil, last_name: nil, email: nil, created_at: nil,
updated_at: nil>, @errors=#<OrderedHash {"last_name"=>
[#<ActiveRecord::Error:0x1085a2c70 @options={:default=>nil},
@base=#<Person id: nil, first_name: nil, last_name: nil, email:
nil, created_at: nil, updated_at: nil>, @type=:blank,
@message=:blank, @attribute=:last_name>], "first_name"=>
[#<ActiveRecord::Error:0x1085a3170 @options={:default=>nil},
@base=#<Person id: nil, first_name: nil, last_name: nil, email:
nil, created_at: nil, updated_at: nil>, @type=:blank,
@message=:blank, @attribute=:first_name>]}>>

Let’s try that again...
>> p.errors.class
=> ActiveRecord::Errors
>> p.errors.each_error {|attr, error|
puts "[#{attr}] #{error}"}
[first_name] can't be blank
[last_name] can't be blank
=> ["first_name", "last_name"]

ActiveRecord::Errors
• When a validation fails, it adds an element
to #errors — an enumerable instance of
ActiveRecord::Errors
• You could also call it the “which validations
failed, and why” array
• If #errors.empty? is true, then the save/
update takes place

• validates_acceptance_of
• The attribute must exist (e.g., a checkbox
indicating user acceptance of site rules)
• validates_associated
• The object to which we’re connect via an
association must also be valid

• validates_confirmation_of
• Did PARAM equal PARAM_confirmation?
(Think of password confirmation...)
• validates_each
• Takes a block, and validates each named
attribute against the block

• validates inclusion of
• validates_exclusion_of
• The attribute must (or may not) be a
member of a particular array
• validates_format_of
• The attribute must match a regular
expression to be valid

• validates_length_of / validates_size_of
• The attribute may be no more (and/or no
less) than a speciﬁed length
• validates_numericality_of
• The attribute must be a valid number
• validates_uniqueness_of

Validator options
• Many validators can take options
• For example:
validates_numericality_of :age,
:only_integer =>
true, :greater_than =>
0, :less_than_or_equal_to => 120

Messages
• Each validation has a default message
• We saw those messages when looking at the
errors object
• Every validation lets you customize the
message with the :message parameter
validates_presence_of :last_name,
:message => "What, you think you're
Madonna?"

Checking validity
• The #valid? method returns true or false
• It also sets the errors object
>> q.valid?
=> false
>> q.errors
=> #<ActiveRecord::Errors:0x1089712e8
@base=#<Person id: nil, first_ ...

Custom validators
• Sometimes, you need to validate in a
particular way
• The easiest way is to deﬁne a new method
in the model class
• If the error exists, invoke
errors.add_to_base, with a string
containing the message

Custom validator
validate :last_name_must_be_lerner
def last_name_must_be_lerner
errors.add_to_base("Sorry, but your
last name must be 'Lerner'") unless
last_name.downcase == 'lerner'
end

Testing our validator
'Reuven', :last_name => 'Lerner')
=> #<Person id: nil, first_name: "Reuven",
last_name: "Lerner", email: nil, created_at:
nil, updated_at: nil>
>> p.valid?
=> true
>> p.last_name = 'Smith'
=> "Smith"
>> p.valid?
=> false

Use validations!
• They’re not database-level constraints, but
they can be extremely ﬂexible and powerful
• The built-in validators have a lot of options
• Use them!
• Only write a custom validator if you
really need to do so

Callbacks
• Validations ﬁre automatically when we save
or update our model. How?
• Answer:They’re a form of “callback,” a
method that is invoked automatically when
something happens
• ActiveRecord offers many “hooks” that let
you deﬁne callbacks

Uses for callbacks
• Update a counter, or total column (and
avoid doing so in the controller)
• Encrypt user passwords
• Write to an audit trail about changes to a
particular model

When callbacks can run
before_validation
before_validation_on_create / ...on_update
after_validation
after_validation_on_create / ...on_update
before_save
before_create / before_update
after_create / after_update
after_save

Downcase e-mail
>> p = Person.new(:first_name => 'Reuven', :last_name
=> 'Lerner', :email => 'Reuven@Lerner.co.IL')
=> #<Person id: nil, first_name: "Reuven",
last_name: "Lerner", email: "Reuven@Lerner.co.IL",
>> p.save
=> true
jruby-1.5.3 > p
"2010-10-25 17:24:19", updated_at: "2010-10-25
17:24:19">

How did we do that?
before_save :downcase_email
def downcase_email
email.downcase!
end

How did we do that?
def downcase_email
email.downcase!
end
Declare the callback

How did we do that?
def downcase_email
email.downcase!
end
Declare the callback
Deﬁne the
callback method

Declaring callbacks
• Don’t invoke them!
• They’re invoked automatically
• Don’t define them!
• Redefining them will have weird effects
• Class methods, not instance methods
• Executed in order of definition

Multiple callbacks
• You can have as many callbacks as you want
• You can run more than one callback on a
given hook
• You can run more than one callback on a
given attribute

Good uses of callbacks
• Automatic transformations
• Automatic calculations (e.g., price totals)
• Logging
• Creation of behind-the-scenes objects
• Actions that should occur when an object
is saved or updated

Bad uses of callbacks
• Additional validations
• Use a validator instead! (Which is a form
of callback, after all)
• Handle session-related items
• Remember the M-V-C separation

Return values from
callbacks
• Normally, callbacks don’t return values
• But if you return false:
• In a before_* callback, all later callbacks
and the action are cancelled!
• In an after_* callback, all later callbacks
are cancelled

Oh, yeah
• Don’t call “save” or “update_attribute”
inside of a callback.
• It’ll really hurt. A lot.

Looking at callbacks
• FYI, the callback on a model are stored in a
“callback chain” object
• You can get at it with
Person.before_save_callback_chain
• Better yet:
Person.before_save_callback_chain.each {|
c| puts c.method}; nil

Observers
• We won’t go into this today
• Each AR object can have an observer
• Observer method names are the same as
callbacks (after_save, etc.)
• So what’s the difference?
• Semantic — in/out of the model

Dirty objects
>> p = Person.first
"2010-10-13 18:01:03", updated_at: "2010-10-13
18:01:03">
=> "Bibi"
>> p.changed?
=> true
>> p.changed
=> ["first_name"]

More with dirty objects
>> p.changes
=> {"first_name"=>["Reuven", "Bibi"]}
>> p.first_name_changed?
=> true
>> p.first_name_was
=> "Reuven"

More with dirty objects
>> p.changes
=> {"first_name"=>["Reuven", "Bibi"]}
>> p.first_name_changed?
=> true
>> p.first_name_was
=> "Reuven"
Each changed attribute,
with old and new values

Deﬁning methods
• It’s common (and expected) to write
methods for your model
• No model methods:Your controller is
probably doing too much!
• It’s OK for your model methods to talk to
other models via associations...
• ... but your controller probably shouldn’t!

Common methods
• Return a particular piece of information
about the model
• String, calculation, result of a database
query, statistics about the object
• Return an array, based on associations or
other properties
• Associations are available for free!

Named scopes
• An easy way to create methods
• Basically, a wrapper around “ﬁnd”
• Example, from a forum-posting model:
named_scope :questions, :conditions
=> { :is_question => true }, :order
=> "created_at DESC"

Parameterized scopes
named_scope :created_since,
lambda { |since| { :conditions =>
['created_at >= ? ', since] }}
named_scope :search,
lambda { |term| { :conditions =>
["lower(name) ilike ? ", term] } }

Parameterized scopes
named_scope :created_since,
lambda { |since| { :conditions =>
['created_at >= ? ', since] }}
named_scope :search,
lambda { |term| { :conditions =>
["lower(name) ilike ? ", term] } }
Named scope is a procedure
object taking one parameter

When?
• When should you create a named scope?
• Simple answer:Whenever you invoke “ﬁnd”
in a controller, replace it with a named
scope.
• It cleans up the controller code a lot.
• Note: Named scopes are class methods,
not instance methods

Chaining scopes
# in class Shirt
named_scope :red, :conditions => {:color
=> 'red'}
named_scope :dry_clean_only, :conditions
=> ['dry_clean_only = ?', true]
Shirt.red
Shirt.dry_clean_only
Shirt.red.dry_clean_only

Chaining scopes
# in class Shirt
named_scope :red, :conditions => {:color
=> 'red'}
named_scope :dry_clean_only, :conditions
=> ['dry_clean_only = ?', true]
Shirt.red
Shirt.dry_clean_only
Shirt.red.dry_clean_only
Composition of scopes!

Transactions
Group.transaction do
group = Group.create!(:name => group_name)
Membership.create!(:person => @person,
:group => group,
:is_administrator => true,
:status => 'approved')
"Successfully created the group '#{group_name}'."
end

Transactions
Group.transaction do
group = Group.create!(:name => group_name)
Membership.create!(:person => @person,
:group => group,
:is_administrator => true,
:status => 'approved')
"Successfully created the group '#{group_name}'."
end
Class method “transaction”

Transaction tips
• Transactions are per connection, not model
• So use whatever class you want
• Failure raises ActiveRecord::Rollback
• These only work in databases that support
transactions (i.e., not MySQL’s ISAM)
• Nested transactions work, but are often
translated into “savepoints”

Declarations
• has_one, has_many, and belongs_to are
class methods
• (I think of them as declarations)
• All they do is deﬁne methods!
• So has_many might seem magical, but all it’s
doing is deﬁning a bunch of methods on
your object

Adding declarations
• Add a module to the lib directory
• (Automatically included)
• Use Module#included? to create one or
more class methods in the including class
• Voila! Now you can do it, too
• e.g., adds_priority_tags_to_errors

:include
• When you perform a “ﬁnd”,
consider :include
• It retrieves another object with the current
one
• Since the result is cached for this request,
no more database retrievals are needed
• A major speedup in many cases

:include example
Person.all.each {|p| puts
p.pets.inspect}
Person.all(:include
=> :pets).each {|p| puts
p.pets.inspect}

Optimistic locking
• Add a lock_version ﬁeld to your model,
with a default value of 0
• Voila! Now you can stop people from
saving older versions on top of newer ones
• Each save/update increments lock_version
• If an older version is saved/updated, a
StaleObjectError exception is raised

Pessimistic locking
• If you pass :lock => true to ﬁnd, you’ll get
an exclusive lock on the row
• Uses SELECT .. FOR UPDATE
• If you need a different string, then pass a
string, rather than “true”
• I’ve never used this
• But hey, I use PostgreSQL...

Seed data
• Don’t put data in a migration ﬁle!
• Instead, use the special db:seed Rake task
• File is db/seeds.rb
• Add lots of calls to “create” in here
• It only adds data — no doubles, erasing,
or otherwise touching of existing data

Changing behavior
• Don’t write an “initialize” method for your
ActiveRecord object. This will probably fail.
• Instead, use the after_initialize hook
• Or write a plugin that monkey-patches
ActiveRecord!

YAML
• You can turn any ActiveRecord object into
YAML with the .to_yaml

YAML
>> puts Person.first.to_yaml
--- !ruby/object:Person
attributes:
created_at: 2010-10-13 18:01:03.330099
updated_at: 2010-10-13 18:01:03.330099
id: "6"
last_name: Lerner
email: reuven@lerner.co.il
first_name: Reuven
attributes_cache: {}

JSON
>> puts Person.first.to_json
{"person":
{"created_at":"2010-10-13T18:01:03Z","
updated_at":"2010-10-13T18:01:03Z","id
":
6,"last_name":"Lerner","first_name":"R
euven","email":"reuven@lerner.co.il"}}
=> nil

XML
>> puts Person.first.to_xml
<?xml version="1.0" encoding="UTF-8"?>
<person>
<created-at type="datetime">2010-10-13T18:01:03Z</
created-at>
<email>reuven@lerner.co.il</email>
<first-name>Reuven</first-name>
<id type="integer">6</id>
<last-name>Lerner</last-name>
<updated-at type="datetime">2010-10-13T18:01:03Z</
updated-at>
</person>
=> nil

:include
• If you want to include one or more
associated objects in the JSON or XML
output, just use :include

JSON with :include
>> puts Person.first.to_json(:include => :pets)
{"person":
{"created_at":"2010-10-13T18:01:03Z","updated_a
t":"2010-10-13T18:01:03Z","pets":
[{"name":"Spot","created_at":"2010-10-14T07:43:
59Z","updated_at":"2010-10-14T07:43:59Z","id":
1,"person_id":6,"animal_type":"dog"}],"id":
6,"last_name":"Lerner","first_name":"Reuven","e
mail":"reuven@lerner.co.il"}}
=> nil

>> puts Person.first.to_xml(:include => :pets)
<?xml version="1.0" encoding="UTF-8"?>
<person>
<created-at type="datetime">2010-10-13T18:01:03Z</created-at>
<email>reuven@lerner.co.il</email>
<first-name>Reuven</first-name>
<last-name>Lerner</last-name>
<updated-at type="datetime">2010-10-13T18:01:03Z</updated-at>
<pets type="array">
<pet>
<animal-type>dog</animal-type>
<created-at type="datetime">2010-10-14T07:43:59Z</created-at>
<name>Spot</name>
<person-id type="integer">6</person-id>
<updated-at type="datetime">2010-10-14T07:43:59Z</updated-at>
</pet>
</pets>
</person>
=> nil

Other options
• :except — ignore certain attributes/tags
• :only — we only want some attributes
• :methods — invoke methods and include
their output in the XML
• Or hand a block to to_xml, and then you
can use builder (Ruby’s XML-generating
facility) to create whatever you want!

Better XML
• If you want to customize the XML, then use
an XML view (instead of an HTML view)
• “Builder” allows you to create XML ﬁles
very easily, with any tags and attributes
• We’ll talk about this further when we
discuss views

Plugins
• Plugins modify default Rails behavior
• They go in /vendor/plugins
• Many modify ActiveRecord’s behavior
• Be careful before installing a plugin... they’re
quite useful, but you don’t want clashes

Example: acts_as_tree
• Create a table with a “parent” attribute
• If you say “acts_as_tree”, then you get
methods for “parent,” “children,” and so
forth
• In very widespread use (written by DHH)

Some others
• acts_as_list
• acts_as_nested_set
• acts_as_taggable
• acts_as_taggable_on_steroids
• acts_as_state_machine

190 acts_as gems!

Contacting me
• Call me in Israel: 054-496-8405
• Call me in the US: 847-230-9795
• E-mail me: reuven@lerner.co.il
• Interrupt me: reuvenlerner (Skype/AIM)

ActiveRecord 2.3

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (13)

Similaire à ActiveRecord 2.3

Similaire à ActiveRecord 2.3 (20)

Plus de Reuven Lerner

Plus de Reuven Lerner (9)

Dernier

Dernier (20)

ActiveRecord 2.3