ActiveRecord 2.3

ActiveRecord 2.3Reuven M. Lerner

October 20th, 2010

1Monday, October 25, 2010

What is a database?

Database

Store data confidently

Retrieve data flexibly

Relational databases

Define tables, store data in them

Database

Retrieve data from related tables

Database communication

SQL goes hereCREATE TABLE

INSERTUPDATEDELETE

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)

ORMRuby

Database

ORMRuby

Database

Write in Ruby

ORMRuby

Database

Write in Ruby

ORM translates to SQL, sends to database

ORMRuby

Database

Write in Ruby

Results goto ORM

ORMRuby

Database

Write in Ruby

Results goto 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 define 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 difficult and frustrating

• “Syntactic vinegar”

Using ActiveRecord

• Typically, we subclass ActiveRecord::Base in each of our model files

• That is, all of the classes defined 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 official release is 3.0, and much online documentation will reflect that

• So when you look online, check the version number!

Person model

class Person < ActiveRecord::Base

Person model

Singular class name

Person model

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 file

• Migrations are in db/migrate

• Each has a unique filename, 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 endend

Migrate forward

Migrate backward

Migrate forward

Migrate backward

Data types

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 file 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 defined in the database, not in the model

• This means that column names and types are set in the migrations

• The easiest way to find 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) ==========================================

~/Downloads/foo$ rake db:migrate (in /Users/reuven/Downloads/foo)

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

~/Downloads/foo$ rake db:migrate (in /Users/reuven/Downloads/foo)

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 whatabout these?

Assumptions

• Convention over configuration!

• 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 config/database.yml

• The only configuration 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

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

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 definition 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

>> 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>

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 `assign_attributes'

from /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.3.8/lib/active_record/base.rb:2902:in `each'

from /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.3.8/lib/active_record/base.rb:2775:in `attributes='

from /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.3.8/lib/active_record/base.rb:2473:in `initialize'

from (irb):44:in `new'

from (irb):44

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:2902:in `each'

from /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.3.8/lib/active_record/base.rb:2775:in `attributes='

from /opt/local/lib/ruby/gems/1.8/gems/activerecord-2.3.8/lib/active_record/base.rb:2473:in `initialize'

from (irb):44:in `new'

from (irb):44

Updating fields

>> p.first_name = 'Bibi'

=> "Bibi"

>> p.save

=> true

Updating fields

=> "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 file?

• 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 :first_name

• first_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

• This is the workhorse of ActiveRecord

• The “find” method is really a lot of different methods with a single interface

find 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 find with an ID — one object (or raises an exception)

• find 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'})=> []>> Person.all(:conditions => {: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 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, SQL style

>> Person.all(:conditions => "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 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">]

>> Person.all(:conditions => "first_name = 'Reuven'")

String

>> Person.all(:conditions => "first_name = '#{@person.first_name}'")

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...)

Sweden, last month

Interpolating parameters

• Instead of:>> Person.all(:conditions => "first_name = '#{@person.first_name}'")

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

Array of strings

• Use:>> Person.all(:conditions => ["first_name = ?", @person.first_name]) Question mark

Array of strings

• Use:>> Person.all(:conditions => ["first_name = ?", @person.first_name]) 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>> Person.all(:conditions => "first_name = 'Reuven'", :order => 'created_at')

Descending order>> Person.all(:conditions => "first_name = 'Reuven'", :order => 'created_at DESC')

Combining

>> Person.all(:order => 'last_name ASC, created_at DESC')

=> [#<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">, #<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">, ...

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 filtering, too — so conditions are better than #all and #select

• Returns the first 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

find_by_first_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: "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">]

Many find thiseasier to read

Add “all” toget 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", last_name: "Lerner", email: "reuven@lerner.co.il", created_at: "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

• 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

• 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 file

• 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

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, define 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>>> spot = Pet.new(:animal_type => 'dog', :name => 'Spot', :person => Person.first)=> #<Pet id: nil, animal_type: "dog", name: "Spot", person_id: 6, created_at: nil, updated_at: nil>

Here we use the ID

Here we use the object

New “person” method!

>> spot.person

Pet e-mail (p-mail?)

• Pets use their owner’s e-mail address

• One way is to define 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

Easier: Delegation!

belongs_to :person

delegate :email, :to => :person

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

>> 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

Problem solved

>> rover = Pet.new

>> 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

Using has_one>> p = Person.first

>> 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

>> 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">

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

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

Even though we used “new”, the object was saved

Adding

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

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

Update person.rb

has_many :person_pets

has_many :pets, :through => :person_pets

Update person.rb

end has_many :throughconnects our models

via the join table

Update pet.rb

has_many :people, :through => :person_pets

Now it all works!

>> spot.people=> []>> spot.people << Person.first=> [#<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">]>> spot.people=> [#<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">]

From the other side...

>> Person.first.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">]

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.first.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

Example: Auto-destroy

has_many :person_pets, :dependent => :destroy

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 first and last names:

validates_presence_of :first_name

validates_presence_of :last_name

Or, on a single line

validates_presence_of :first_name, :last_name

• I prefer the multi-line version, for easier adding and removing of validations

So, what now?

>> p = Person.new

>> p.save!

ActiveRecord::RecordInvalid: Validation failed: First name can't be blank, Last name can't be blank

So, what now?

>> p = Person.new

>> p.save!

ActiveRecord::RecordInvalid: Validation failed: First name can't be blank, Last name can't be blank

Each violationis 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 specified 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 define 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'

Testing our validator>> p = Person.new(:first_name => '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 flexible 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 fire 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 define 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", created_at: nil, updated_at: nil> >> p.save => true jruby-1.5.3 > p => #<Person id: 12, first_name: "Reuven", last_name: "Lerner", email: "reuven@lerner.co.il", created_at: "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!

How did we do that?

def downcase_email

email.downcase!

Declare the callback

How did we do that?

def downcase_email

email.downcase!

Declare the callback

Define 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

=> "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

Defining 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 “find”

• 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 should you create a named scope?

• Simple answer: Whenever you invoke “find” 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}'."

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}'."

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 define methods!

• So has_many might seem magical, but all it’s doing is defining 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 “find”, 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 field 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 find, 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 file!

• 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!

• You can turn any ActiveRecord object into YAML with the .to_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: Reuvenattributes_cache: {}

>> 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":"Reuven","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_at":"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","email":"reuven@lerner.co.il"}}

=> nil

>> puts Person.first.to_xml(:include => :pets)

<?xml version="1.0" encoding="UTF-8"?>

<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>

<animal-type>dog</animal-type>

<created-at type="datetime">2010-10-14T07:43:59Z</created-at>

<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 files 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

Technology

Transcript of ActiveRecord 2.3

Disconnecting the Database with ActiveRecord

ActiveRecord Query Interface (1), Season 1

Library of Congress Cataloging-in-Publication Dataptgmedia.pearsoncmg.com/images/9780321659361/samplepages/...Caching with Memcached 155 The Memcached Client and ActiveRecord 156 Time-Based

ActiveRecord & ARel

Osteosynthese 2.3 Fraktur und Rekonstruktion Osteosynthesis 2.3 ...

Filtering, Searching, and Sorting ActiveRecord Lists Using Filterrific

ActiveRecord vs Mongoid

Datenbankapplikationen mit Ruby on Railsdbs/2011/PDF/dbs2011-06-20.pdf · has_many_and_belongs_to_many :students end Lecture Student n m class Student < ActiveRecord::Base has_many_and_belongs_to_many

CVE-2012-2661: ActiveRecord SQL injection

ActiveRecord::Callbacks. Готовим правильно.

Advanced Arel: When ActiveRecord Just Isn't Enough

Hidden features in ActiveRecord and the future

Intro to Rails ActiveRecord

Liskov Substitution Principle(ELLS §10.5)€¦ · Rails’ ActiveRecord module defines an AbstractAdapter for connecting to databases. Subclasses of AbstractAdapter exist for each

Refactoring ActiveRecord Models

From ActiveRecord to EventSourcing

Replacing ActiveRecord With DataMapper

Продвинутое использование ActiveRecord в Yii2

Rails 3 ActiveRecord

ActiveRecord Query Interface (2), Season 2