The simplest form of finder is the one which returns all of the records in a table:

>> results = Person.find :all
=> [#<Person:0xb7433d78 ...>, #<Person:0xb7433d3c ...>, #<Person:0xb7433d00 ...>, #<Person:0xb7433cc4 ...>, #<Person:0xb7433c88 ...>]

(Again, output is truncated for brevity.)

This finder returns an array of model instances; in this case, instances of our Person class. We can iterate through these with the standard array methods provided by Ruby, e.g.

>> results.each { |record| puts record.last_name }
Harker
Smith
Smith
Junket
Tribble

It is also possible to limit the number of records returned, e.g. to return the first 5 records (when the people table is ordered by id):

>> Person.find :all, :limit => 5

Or to get a subset of records starting at some offset:

>> Person.find :all, :limit => 5, :offset => 5

The above gets records 6-10 from the people table (ordered by the id field).

ActiveRecord provides a default getter method for each attribute of a model class; these attributes get mapped onto fields in the database table. However, there are some situations where the default getters and setters are inadequate. For example, if you want to provide an alternative representation of a field or combine multiple real attributes into a single output attribute, you might need a custom getter.

In Rails, a pseudo-field derived from other real fields is referred to as a virtual attribute: while it is derived from and accessed in the same way as actual field values in the database table, a virtual attribute doesn't have a corresponding field of its own.

We'll write a full_name method, which will concatenate a person's title, first name, and last name into a formatted string. We also need to cope with situations where title has not been set, as it is not a required attribute:

class Person < ActiveRecord::Base
# ... other methods ...
def full_name
out = (title.blank? ? '' : title + ' ')
out + first_name + ' ' + last_name
end
end

We'll make use of this in the next few sections when displaying records we retrieve.

If we want to order the records, we can do this by passing an extra argument to the find method call:

>> results = Person.find :all, :order => 'last_name DESC'
...
>> results.each { |record| puts record.full_name }
Mrs. Jo Harker
Ms. Sarah Junket
Mr. Frank Smith
Dr. Elliot Smith
Mr. Jeff Tribble

Notice that the records are now ordered in descending order by last name (which is why Frank Smith comes before Elliot Smith); you can specify ASC to sort in ascending order (the default, if you specify neither ASC or DESC). You can pass any SQL fragment, which would ordinarily follow the ORDER BY keywords in a SQL statement, e.g.

>> results = Person.find :all, :order => 'last_name, first_name'
...
>> results.each { |record| puts record.full_name }
Mrs. Jo Harker
Ms. Sarah Junket
Dr. Elliot Smith
Mr. Frank Smith
Mr. Jeff Tribble

(Sorting by last name in ascending order, then by first name in ascending order where records have matching last names.)

We can find a single record by ID:

>> Person.find 4
=> #<Person:0xb74a91d4 ...>

Note that this doesn't return an array, but a single instance of the Person model class.

What ActiveRecord does in the background is execute the following MySQL query:

SELECT * FROM people WHERE (people.id = 4) LIMIT 1;

In some cases, you won't want to use all of the fields in the table. You can improve the efficiency of your queries by just returning the fields you need using the :select option:

>> Person.find 4, :select => 'first_name'
=> #<Person:0xb74d8604 @attributes={"first_name"=>"Sarah"}>

In this example, the query is restricted to just returning the first_name field. Note that you will need to retrieve a person's ID if you want to be able to save the model instance back to the database. Also note the :select will work with find :all, too.

We can also retrieve an array of records with specific IDs:

>> Person.find [1,3]
=> [#<Person:0xb74a3d4c ...>, #<Person:0xb74a3d10 ...>]

One method for finding records by criteria is by passing a :conditions option to find. For example, to find the first person with the last name "Junket":

>> Person.find :first, :conditions => "last_name = 'Junket'"

Or to find everyone with the surname "Smith":

>> Person.find :all, :conditions => "last_name = 'Smith'"

The :conditions option can also be passed an array, consisting of a SQL "template" as the first element, followed by the values to substitute into the template:

>> Person.find :all, :select => 'last_name, first_name',
:conditions => ["last_name = ?", 'Smith']
=> [#<Person:0xb74556ec ...>, #<Person:0xb74556b0...>]

Note what we've done here is passed an array to the :conditions find option, with a template and a substitution:

:conditions => ["last_name = ?", 'Smith']

The template should be a SQL fragment, suitable for placing after the WHERE clause in a SQL query. Any values to be substituted are represented by question marks (?) in the template. The :conditions array can be as complex as you want:

>> Person.find :all, :conditions => ["date_of_birth < ? AND last_name = ?", 20.years.ago, 'Smith']
=> [#<Person:0xb741da58...>]

This finds everyone born more than 20 years ago with the last name "Smith".

It is also possible to use LIKE statements as :conditions to perform wild-card matches. However, note that these aren't as platform-portable as the above SQL statements. For example, to perform case-insensitive matches in PostgreSQL, you have to use the ILIKE keyword (rather than LIKE); while MySQL defaults to case-insensitive matching.

In the case of MySQL, we can do a wild-card match using LIKE with this syntax (to get everyone whose first name starts with "j" or "J"):

>> results = Person.find :all, :conditions => "first_name LIKE 'j%'"
...
>> results.each { |record| puts record.full_name }
Mr. Jeff Tribble
Mrs. Jo Harker

ActiveRecord provides one further set of conveniences for finding records: dynamic attribute-based finders. This mouthful means that you can make up finders based on field names in the table, on the fly. For example, to get all the people in the database with the first name "Elliot".

>> Person.find_by_first_name 'Elliot'

You can also specify multiple fields to filter on by joining the names of the fields with "and", e.g. to get everyone with the first name "Elliot" and last name "Smith":

>> Person.find_by_first_name_and_last_name 'Elliot', 'Smith'

By default, dynamic finders will return a single record; but they can also return an array by using find_all_by, instead of find_by:

Person.find_all_by_last_name "Smith"

Note that you can also pass standard finder options to dynamic finders, like :select and :conditions:

>> Person.find_by_first_name 'Elliot', :select => 'first_name'
>> Person.find_by_last_name 'Smith', :conditions => ['date_of_birth < ?', 20.years.ago], :select => 'first_name'

One last resort for performing queries is to pass the raw SQL to ActiveRecord yourself. Instead of using the standard find method, you create the SQL "manually" (as you would if crafting a PHP application without an ORM layer). You then execute this string using the find_by_sql method:

>> Person.find_by_sql "SELECT first_name FROM people"

Note that find_by_sql returns an array of instances.

Don't forget that you can add your own finder-style methods to your class for extra convenience, too. In our Intranet application, we are very often going to want to get a list of everyone in the people table, sorted by name. We can write a wrapper round find to do this, inside the Person class:

class Person
...
def self.find_all_ordered
find :all, :order => 'last_name, first_name'
end
end

Specifying a method name starting with the keyword self creates a new class-level method. We can call it like this:

>> results = Person.find_all_ordered
...
>> results.each { |record| puts record.full_name }
Mrs. Jo Harker
Ms. Sarah Junket
Dr. Elliot Smith
Mr. Frank Smith
Mr. Jeff Tribble

(This is the same output as when we used find in the section Sorting Records.)

ActiveRecord does a lot of work in the background creating SQL statements for you. If you are curious about what ActiveRecord is doing, you can see the SQL statements in their raw form by reading the RAILS_ROOT/log/development.log file. For example, here's what Person.find :all gets translated into by Rails:

[4;36;1mPerson Load (0.002825)[0m [0;1mSELECT * FROM people [0m

The unusual characters are in the output ("[4;36;1m", "[0m" etc.), are colorization specifications, so that in editors which are capable of understanding ANSI colorization codes, you get different colors for different elements of the log. My preference is to turn off colorization by adding this line to the bottom of the config/environment.rb file:

ActiveRecord::Base.colorize_logging = false

This gives you far more sensible log output:

Person Load (0.000403) SELECT * FROM people

The important part of this, besides the SQL statement, is the number between the brackets. This shows the length of time (in seconds) that the query took to execute.

Looking at the raw SQL queries can sometimes help identify problems with badly-formatted queries, or where large inefficient queries are being generated, which could be slimmed down using find_by_sql. We'll have more to say about the logs in the section on logging in chapter 6.

Unfortunately, if you are looking at logs in Eclipse, you may find that the log file opens in an external editor. You can setup Eclipse to open them instead as follows:

The association should now be set up. Try opening a log file in Eclipse to check if it works.

Recall that in our data structure (see Chapter 2) we specified that each person added to the people table had to meet the following validation criteria:

We can apply these validations by adding checks on the attributes of instances of the Person model, as follows:

class Person < ActiveRecord::Base
validates_presence_of :first_name,
:message => "Please enter a first name"
validates_presence_of :last_name,
:message => "Please enter a last name"
...
end

"<attribute> can't be blank"

# validate when creating new records and updating existing records
# (this is the default)
validates_presence_of :first_name, :on => :save
# ONLY validate when creating new records
validates_presence_of :first_name, :on => :create
# ONLY validate when updating existing records
validates_presence_of :first_name, :on => :update

>> p = Person.new
=> #<Person:0xb7436850 ...>
>> p.save
=> false
>> p.errors
#<Person:0xb7436850 @new_record=true, @errors=#<ActiveRecord::Errors:0xb74349d8 @errors={"first_name"=>["Please enter a first name"], "last_name"=>["Please enter a last name"]} ...>

>> p.errors['last_name']
=> "Please enter a last name"
>> p.errors['first_name']
=> "Please enter a first name"

/^[A-Z0-9._%-]+@[A-Z0-9.-]+.[A-Z]{2,4}$/i

class Person < ActiveRecord::Base
EMAIL_REGEX = /^[A-Z0-9._%-]+@[A-Z0-9.-]+.[A-Z]{2,4}$/i
validates_format_of :email, :with => EMAIL_REGEX,
:message => "Please supply a valid email address"
...
end

>> p = Person.new(:first_name => 'Elliot', :last_name => 'Smith')
=> #<Person:0xb742dbec ...>
>> p.email = 'elliot at example.com'
=> "elliot at example.com"
>> p.save
=> false
>> p.errors['email']
=> "Please supply a valid email address"
>> p.email = '[email protected]'
=> "[email protected]"
>> p.save
=> true

class Person < ActiveRecord::Base
EMAIL_REGEX = /^[A-Z0-9._%-]+@[A-Z0-9.-]+.[A-Z]{2,4}$/i
validates_format_of :email, :with => EMAIL_REGEX,
:message => "Please supply a valid email address"
validates_uniqueness_of :email, :message => "This email address
already exists"
...
end

>> p = Person.new(:first_name => 'William', :last_name => 'Shakes', :email => '[email protected]')
=> #<Person:0xb790f4e0 ...>
>> p.save
=> true

>> p = Person.new(:first_name => 'Bill', :last_name => 'Shakes', :email => '[email protected]')
=> #<Person:0xb790f4e0 ...>
>> p.save
=> false

SELECT * FROM people WHERE (people.email = '[email protected]') LIMIT 1

class Person < ActiveRecord::Base
GENDERS = {'M' => 'male', 'F' => 'female'}
...
end

class Person < ActiveRecord::Base
GENDERS = {'M' => 'male', 'F' => 'female'}
validates_inclusion_of :gender, :in => GENDERS.keys,
:message => "Please select 'M' or 'F' for gender"
...
end

>> p = Person.new
=> #<Person:0xb74ecafc ...>
>> p.gender = 'X'
=> "X"
>> p.save
=> false
>> p.errors
=> #<ActiveRecord::Errors:0xb74e83bc @errors={"gender"=>["Please select 'M' or 'F' for the genre"], ...} ...>
>> p.gender = 'M'
=> "M"
>> p.save
=> true

class Person < ActiveRecord::Base
EMAIL_REGEX = /^[A-Z0-9._%-]+@[A-Z0-9.-]+.[A-Z]{2,4}$/i
validates_format_of :email, :with => EMAIL_REGEX,
:message => "Please supply a valid email address"
validates_uniqueness_of :email,
:message => "This email address already exists"
validates_presence_of :first_name,
:message => "Please enter a first name"
validates_presence_of :last_name,
:message => "Please enter a last name"
GENDERS = {'M' => 'male', 'F' => 'female'}
validates_inclusion_of :gender, :in => GENDERS.keys,
:message => "Please select 'M' or 'F' for the genre"
...
end

The validation code for the Company model in app/models/company.rb is very simple, as we only need to ensure a company has a name:

class Company < ActiveRecord::Base
validates_presence_of :name,
:message => "Please enter a company name"
end

The validation code for the Address model in app/models/address.rb is as follows:

class Address < ActiveRecord::Base
validates_presence_of :street_1,
:message => "Please enter an initial line for the address"
POSTCODE_REGEX = /^[A-Z][A-Z]?[0-9][A-Z0-9]? ?[0-9] [ABDEFGHJLNPQRSTUWXYZ]{2}$/i
validates_format_of :post_code, :with => POSTCODE_REGEX,
:message => "Please enter a valid post code"
def validate_on_create
if Address.find_by_street_1_and_post_code(street_1, post_code)
errors.add_to_base('Street address and post code already exist in the database')
end
end

end

The UK postcode regular expression is from Wikipedia (http://en.wikipedia.org/wiki/UK_postcodes). It will allow some invalid postcodes through; but like the regular expression for email addresses (see section, Checking Against a Regular Expression), it is simple to follow and will catch 95% of cases.

The first line of the address (street_1) is validated, as an initial address line and post code are required to uniquely identify a UK address.

The final validation (highlighted) is the most interesting, as it demonstrates how to perform a custom validation not available using the default Rails methods. This is done by defining a validate_on_create method, which is run to validate any records when they are created.

The validate_on_create method can check attributes on the instance using whichever criteria you like. For example, you could validate a host name against a DNS look-up service or check a country code against a web service (neither of which is possible with the macros). ActiveRecord runs any custom validate_on_create method in tandem with validations defined using the validates_* macros.

In this case, the street_1 and post_code attributes on the new instance are used to look up a record in the addresses table: if an address with matching street_1 and post_code already exists, validation fails, and a generic error message is added to the model instance (add_to_base enables adding an error message to the whole instance, rather than a particular field).

There is validate_on_update method, to be applied only on updates to records; and also a validate method that you can define to perform validation on both record creation and updates.

There are several more esoteric validates_*_of methods, which are summarised below (along with those with already seen), with examples of how you can use them.

Another method worth mentioning is validates_each, which enables you to create a custom validation for one or more attributes by running them through a block. It is used as the basis for Rails' built-in validation methods. See the documentation of ActiveRecord::Validations::ClassMethods for more details of how to use it (and for more details about the methods listed above).

In our application, the testing framework has been automatically applied during our work with the generators. To take advantage of it, we just need to setup a test database. Follow the instructions in the section Creating a Database and System Account to add a new database; the process is summarized below:

mysql> CREATE DATABASE intranet_test;
Query OK, 1 row affected (0.18 sec)
mysql> GRANT ALL PRIVILEGES ON intranet_test.* TO intranet@localhost IDENTIFIED BY 'police73';
Query OK, 0 rows affected (0.25 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

We've used the same database user (intranet) for the intranet_test database as we used for the intranet database: if you prefer, you can use a separate dedicated testing user.

We also need to edit config/database.yml to configure the test database:

test:
adapter: mysql
database: intranet_test
username: intranet
password: police73
socket: /var/run/mysqld/mysqld.sock

Now, we are ready to run the tests from the command line with rake:

$ rake test:units
(in /home/rory/workspace/Intranet)
/usr/bin/ruby1.8 -Ilib:test "/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/
rake/rake_test_loader.rb" "test/unit/person_test.rb" "test/unit/company_test.rb" "test/unit/address_test.rb"
Loaded suite /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader
Started
...
Finished in 0.861688 seconds.
3 tests, 3 assertions, 0 failures, 0 errors

So far, so good. Running the command rake test:units initiates a Rake task, which does the following:

In the next section, we'll see how a test case works, and write our own.

The default test case for the Person model (in test/unit/person_test.rb) is defined as:

require File.dirname(__FILE__) + '/../test_helper'
class PersonTest < Test::Unit::TestCase
fixtures :people
# Replace this with your real tests.
def test_truth
assert true
end
end

The first line loads the test_helper.rb code from another file inside the test directory. This file governs the general behavior of tests; we'll return to it in the next section.

The fixtures method loads some test data into the testing database, using database records defined in YAML files (see the section, Setting Up a Database Connection for more information about YAML). We'll come onto fixtures shortly.

The only default test method is test_truth. This calls the assert method with the argument true, which always returns true (it always passes). We need to replace this dummy method with our own tests.

The next question when applying unit tests to a model is "What should we test?". My answer to that is: test all validations, associations, and utility methods. This might seem excessive, as ActiveRecord already has a test suite, which checks that the validation macros work correctly. However, what we are testing is that instances of our models adhere to the behavior we expect them to have; not whether the validation code performs validation (which we know it does).

Thorough testing like this is particularly important where several people are working on a single code base. As an example, imagine that Rory writes some validation code, which says a person must have a first name. In another part of the application, he makes the assumption that any people he displays will have first names (as he's decided they aren't valid otherwise), and writes some view code, displaying people and their first names.

Meanwhile, Jenny decides that an empty first name is OK: as long as someone has a last name, their first name is unimportant. She removes Rory's validation code for first names.

The next time Rory runs his view code, he gets a regression: any people he tries to display who don't have a first name causes an error to be raised. Rory is perplexed and spends the afternoon working out what's going on.

In this situation, the tests for the validation rules on Person would be broken by Jenny's change to the code. The next time the test suite runs, the test failures will help Rory see what has changed. This makes it much easier to keep the behavior of the application stable, as it forces Jenny to rewrite any tests for the Person model if she wants to change the validation code. It also highlights to Jenny where her change will have an impact on other parts of the application: she can just see which tests fail and fix the code to make them pass again.

Now we have all agreed that testing is a good thing, the next step is to put in place some fixtures: data we can mangle during testing to see whether our expectations about a model hold up.

When you create a model, a blank fixtures file is also created (as well as the test stub discussed previously). The fixtures file is a way of creating dummy records so that each time you run your tests, you have a consistent data set to work from. Rails automatically loads fixtures when running test cases, converting them into records in the test database.

The fixtures file for a model is added to the test/fixtures directory; the name of the fixtures file is the database table name +".yml" (so we have addresses.yml, companies.yml, and person.yml). Each fixtures file is written in YAML: the top level keys are easy-to-remember names for the individual records; indented under each key are the field names and values for each record.

By default, a test case just loads the fixtures for the model under test. If you want to load other fixtures for other models, you can just append extra arguments to the fixtures method call (the first line inside the test class definition):

fixtures :people, :companies

This can be useful when testing associations (see Associations Between Models).

Following our own guidelines, we want to test the find_all_ordered method. To do this, we need at least three records in the person.yml fixture file, so we can check whether they are ordered by last name, and whether two people with the same last name are additionally ordered by first name. During the tests, we will reset attributes on these test records and try to save them back to the test database to exercise other parts of the validation code:

ginger:
id: 1
title: 'Mrs.'
first_name: 'Ginger'
last_name: 'Bloggs'
email: '[email protected]'
gender: 'F'
fred:
id: 2
first_name: 'Fred'
last_name: 'Bloggs'
email: '[email protected]'
gender: 'M'
albert:
id: 3
first_name: 'Albert'
last_name: 'Always'
email: '[email protected]'
gender: 'M'

Notice that the records are put into the YAML file in non-name order, to make sure the sorting is being done by the find_all_ordered method, and isn't just due to the ordering of the fixtures file. Also notice that all of the records are valid, having an email address, first name, last name, and gender. However, it is not necessary to setup the attributes which aren't validated and which we're not testing (like telephone, mobile_phone, etc.).

self.use_transactional_fixtures = true

self.use_transactional_fixtures = false

self.use_instantiated_fixtures = false

self.use_instantiated_fixtures = true

We are now ready to write some tests for the Person model. We have the following expectations about its behavior:

We can add test methods to check each of these expectations.

def test_reject_invalid_email_addresses
@fred.email = 'fred @ hello.com'
assert [email protected]
@fred.email = 'fred [email protected]'
assert [email protected]
end

def test_email_must_be_unique
@fred.email = @albert.email
assert [email protected]
end

def test_must_have_first_name
@fred.first_name = ''
assert [email protected]
end

def test_must_have_last_name
@fred.last_name = ''
assert [email protected]
end

def test_reject_invalid_genders
@fred.gender = 'P'
assert [email protected]
end

def test_full_name_correctly_formatted
assert_equal 'Mrs. Ginger Bloggs', @ginger.full_name
assert_equal 'Fred Bloggs', @fred.full_name
end

def test_find_all_ordered
people_in_order = Person.find_all_ordered
assert_equal 3, people_in_order.size
assert people_in_order[0].last_name <= people_in_order[1].last_name
assert people_in_order[1].last_name <= people_in_order[2].last_name
# fred should come before ginger,
# even though they both have the same surname
assert_equal 'Fred', people_in_order[1].first_name
assert_equal 'Ginger', people_in_order[2].first_name
assert people_in_order[1].first_name <= people_in_order[2] .first_name
end

Several other types of assertion are possible; they are listed below, along with those we've already seen:

These can be used inside test_ methods in a similar way to how we've seen assert and assert_equal being used earlier.

While some of the tests we wrote might feel like overkill, they provide a high degree of peace of mind. I always feel happier when I know my code can be run through a suite of automated tests to highlight any assumptions I've made, which may have been broken.

Another advantage is that the tests become essential for bug fixing as coding progresses. If you come across a bug, you can write a test to replicate the conditions which produce the bug. At this point, the test will fail, as you haven't fixed the bug yet. Then, you can modify the code which causes the bug until the test passes. Before you know it, you are doing test-driven development (TDD).

We haven't approached the Intranet application from a TDD perspective, as TDD is still alien to many developers, and requires a paradigm-shift in how development is approached. However, I would encourage you to at least retro-fit tests to your application, so you get a taste of the benefits; and to code a test to encapsulate each bug you encounter. Over time, you may find that it becomes natural to write tests first then write the code to make them pass. Rails makes this as painless as possible.

The addresses and people tables have a one-to-many relationship in the database. In other words, a record in the addresses table may be related to zero or more records in the people table. The table on the "many" side of the relationship contains a foreign key to the table on the "one" side of the relationship. Ignoring fields irrelevant to the relationship, this can be represented in a standard database diagram as:

In our Rails application, this kind of database relationship is represented in ActiveRecord as an association between the Person and Address models. The association is marked in each of the participating models.

In the Person model:

class Person < ActiveRecord::Base
belongs_to :address
...
end

In the Address model:

class Address < ActiveRecord::Base
has_many :people
...
end

We can generalize the translation from a one-to-many relationship in the database to model associations, so we could use it with any pair of related tables:

Before we can see the effect of this, we need to create an Address:

>> addr = Address.new(:street_1 => '44 Monty Avenue', :city => 'Molltoxeter', :post_code => 'MX12 1YH') # create an address
>> addr.save
=> true

We can now assign this address to a person (assuming, you have at least one person in the database):

>> pers = Person.find :first # find a person
>> pers.address = addr # assign an address to the person
>> pers.save
=> true

This is all you need to associate the new address with the person. Once associated, you can retrieve a person's address using the address method:

>> pers = Person.find :first # find a person
=> #<Person:0xb74a4228 ...>
>> pers.address # retrieve the address for the person
=> #<Address:0xb74a2504 @attributes={"city"=>"Molltoxeter", "updated_at"=>"2006-11-03 14:33:20", "county"=>nil, "street_1"=>"44 Monty Avenue", "street_2"=>nil, "post_code"=>"MX12 1YH", "street_3"=>nil, "id"=>"5", "created_at"=>"2006-11-03 14:33:20"}>

By using the belongs_to method in the Person class, we have appended new address (a getter) and address= (a setter) methods to instances of that class:

If you have multiple people associated with address, you can also query in the other direction, from an address to an array of associated people:

>> a = Address.find :first # find an address
>> a.people # find the people associated with the address
=> [#<Person:0xb744a5c8 ...>, #<Person:0xb744a58c ...>]

class Person < ActiveRecord::Base
belongs_to :company
belongs_to :address
validates_associated :address
...
end

These two tables have a parent-to-child relationship in the database; this is like a one-to-many relationship, except there is at most one record at the "many" side of the relationship. In other words, a record in the addresses table is a parent of zero or one record in the companies table. The "child" in the relationship is the table containing the foreign key:

This might seem a slightly odd way of describing this relationship, but it is perfectly legitimate in ActiveRecord terms: "parent-child" doesn't necessarily denote a dependency in this context.

In the Company class, we add belongs_to:

class Company < ActiveRecord::Base
belongs_to :address
...
end

In the Address class, we add has_one:

class Address < ActiveRecord::Base
has_one :company
...
end

Again, we can generalize this translation:

Testing the association from the console follows a similar pattern to testing the one-to-many relationship of the previous section:

>> comp = Company.find :first # find a company
=> #<Company:0xb7432888 ...>
>> addr = Address.find :first # find an address
=> #<Address:0xb7430150 ...>
>> comp.address = addr # assign the address to the company
=> #<Address:0xb7430150 ...>
>> comp.save # save the company
=> true
>> comp.address # retrieve the address for a company
=> #<Address:0xb7430150 ...>
>> addr.company # retrieve the company associated with an address
=> #<Company:0xb7427f00 ...>

class Company < ActiveRecord::Base
has_many :people
belongs_to :address
validates_presence_of :name,
:message => "Please enter a company name"
validates_presence_of :address,
:message => 'Address must be supplied'
validates_associated :address,
:message => 'Address is invalid'

end

This relationship is very similar to the addresses to people relationship:

It can be marked in the Company model class with:

class Company < ActiveRecord::Base
has_many :people
...
end

And in the Person class with:

class Person < ActiveRecord::Base
belongs_to :company
# ... other methods ...
end

class Person < ActiveRecord::Base
# ... other methods ...
validates_associated :company
end

Our application doesn't (yet) contain any many-to-many relationships in the database structure. But it's easy to think of situations where we might want to have this kind of relationship. For example, Ken might decide he wants to be able to categorise companies: each company will have zero or more categories, and each category will have zero or more associated companies. This would require a many-to-many relationship.

The typical way of implementing a many-to-many relationship in a database is by adding a link table between the two related tables:

In the case of categories and companies, we might end up with:

ActiveRecord makes it convenient to manage the associations between the models for these tables: use the method has_and_belongs_to_many in each model:

class Categories < ActiveRecord::Base
has_and_belongs_to_many :companies
...
end
class Companies < ActiveRecord::Base
has_and_belongs_to_many :categories
...
end

We can generalize this to the following guidelines:

In our database structure, we specified that when an address is deleted, we should remove its associated company. This makes sense, given that we don't want any companies to have invalid addresses; without the dependency, we could delete an address, but still have references to it in the company_id field of the companies table.

To specify the dependency, pass an optional :dependent => :destroy option to the has_one method call in the parent class:

class Address < ActiveRecord::Base
has_one :company, :dependent => :destroy
...
end

The effect of this is to delete a company when its associated "parent" address is deleted. If you are going to use this method for dependency tracking, you need to be clear about the consequences, and ensure that project stakeholders are in agreement: do they really want cascading deletion of companies if an address is removed?

Also note that you can specify other :dependent options with the has_one method:

Similarly, you can use a :dependent option with the has_many method, as used in the Company class, e.g.

Note that you can't set a :dependent option when using has_and_belongs_to_many.

It's often useful to test validation of associations, as well as validation of attributes. For example, in our model, we have a custom validation which checks whether the address_id attribute references a real Address in the database. We can write a unit test for the Company model which checks this validation code, as follows.

First, create a fixture for a valid address in test/fixtures/addresses.yml:

acme_hq:
id: 1
street_1: '14 Blockfield'
street_2: 'Minsterton'
city: 'Jupiterton'
post_code: 'BX1 4FG'

Next, create a fixture for a company in test/fixtures/companies.yml:

acme:
id: 1
name: 'Acme'
address_id: 1

Note how this references the valid address_id (= 1) for the fixture we created above.

Load the addresses fixtures into the unit test for Company in test/unit/company_test.rb:

class CompanyTest < Test::Unit::TestCase
fixtures :companies, :addresses
...
end

Finally, write a test method to check that the validation code for the association behaves as expected:

class CompanyTest < Test::Unit::TestCase
fixtures :companies, :addresses
def test_must_have_real_address
# Should fail with invalid address
@acme.address = nil
assert [email protected]
# Should save when assigned a valid address
@acme.address = @acme_hq
assert @acme.save
end
end