ADVANCED ACTIVE RECORD: ENHANCING YOUR MODELS in Font

Generating QR in Font ADVANCED ACTIVE RECORD: ENHANCING YOUR MODELS

Specifies the class name of the association. Used when the class name can t be inferred from the association name. Specifies the conditions that the associated object must meet in order to be included as a WHERE SQL fragment. Specifies the foreign key used for the association in the event that it doesn t adhere to convention of being the lowercase, singular name of target class with _id appended. Specifies the order from which the associated object will be picked as an ORDER BY SQL fragment. Specifies that the associated object should be removed when this object is. If set to :destroy, the associated object is deleted using the destroy method. If set to :delete, the associated object is deleted without calling its destroy method. If set to :nullify, the associated object s foreign key is set to NULL.

has_one :location, :class_name => 'Address'

has_one :address, :conditions => "active = 1"

has_one :address, :foreign_key => 'location_id'

has_one :address, :order => "created_at DESC"

One-to-many associations describe a pattern where a row in one table is related to one or more rows in another table. Examples would be an Email that has many Recipients, or a Magazine that has many Subscriptions. It s time to say good-bye to contrived examples and put these principles to work in our events application.

When we first started the events application, we decided to let anyone create new events. This worked fine when there was only one person using the system, but we want this to

be a multiple-user application and let different people sign up, sign in, and start managing their own events, separately from one another. Up until now, our events have been orphaned they don t belong to anyone. We re going to remedy that now by creating a User model and associating users with events. In our system, each event is going to belong to a user, and a user may have many events. Figure 5-3 illustrates this association.

Just as you saw in the previous chapter, the model generator creates, among other things, a model file in app/models and a migration in db/migrate. Open db/migrate/ 003_create_users.rb and give it the schema definition shown in Listing 5-2 (add the following code to the file).

class CreateUsers < ActiveRecord::Migration def self.up create_table :users do |t| t.column :login, :string t.column :email, :string t.column :password, :string end # Add a foreign key reference to users in the events table add_column :events, :user_id, :integer end

This is standard migration fare. In the self.up definition, we used the create_table method to create a new users table. The new table object is yielded to the block in the variable, t, on which we call the column method to create each row. Along with the standard login and email fields, we re specifying a hashed_password field, which we ll use for authentication, as we ll explain in the Reviewing the Updated Models section later in this chapter. The primary key, id, will be created automatically, so there s no need to specify it here. Pay particular attention to the user_id column in the self.up section. It s the foreign key reference column we ve been talking so much about. Also note that its type is :integer. That s important, because it s referring to a numeric id. Now all we need to do is run the migration and create the table using the db:migrate Rake task. Run the migration with the following command:

== CreateUsers: migrating ===================================================== -- create_table(:users) -> 0.0035s -- add_column(:events, :user_id, :integer) -> 0.0065s == CreateUsers: migrated (0.0103s) ============================================

With the table and foreign keys in place, Listings 5-3 and 5-4 show how we declare the one-to-many association in our Event and User models. Add these to the relevant models now.