Rails%203%20In%20Action

264 CHAPTER 10 Tracking state
Good, now you’ve got a way to test this state message that should be appearing when a
comment changes the state of the ticket. Now, you’d like to track the state the ticket
was at before the comment as well as the state of the comment itself. To track this extra
attribute, you’ll create another field on your comments table called previous_state
_id. Before you save a comment, you’ll update this field to be the current state of the
ticket. Let’s create a new migration to add the previous_state_id field to your
comments table by running the following command:
rails g migration add_previous_state_id_to_comments previous_state_id:integer
Again, Rails is pretty smart here and will use the name of the migration to infer that
you want to add a column called previous_state_id to a table called comments. You
only have to tell it what the type of this field is by passing previous_state_id
:integer to the migration.
If you open up this migration now, you’ll see that it defines a change method
which calls the add_column method inside it. You can see the entire migration shown
in the following listing.
Listing 10.19 db/migrate_[date]_add_previous_state_id_to_comments.rb
class AddPreviousStateIdToComments < ActiveRecord::Migration
def change
add_column :comments, :previous_state_id, :integer
end
end
It’s done this way because Rails knows how to roll back this migration easily. It’s a simple
call to remove_column passing in the first two arguments in this method.
You don’t need to do anything else to this migration other than run it. Do this now
by running rake db:migrate and rake db:test:prepare. This field will be used for
storing the previous state’s id so that you can then use it to show a state transition on a
comment, as pictured in figure 10.11.
With this little bit of information, users can see what comments
changed the ticket’s state, which is helpful for determining what
steps the ticket has gone through to wind up at this point.
To use the previous_state_id field properly, you’re going to
need to add another callback to save it.
10.3.2 Another c-c-callback
Figure 10.11
A state transition
To set this field before a comment is created, you use a before_create callback on the
Comment model. A before_create callback is triggered—as the name suggests—
before a record is created, but after the validations have been run. This means that this
callback will only be triggered for valid objects that are about to be saved to the database
for the first time.