Rails%203%20In%20Action

Viewing tickets
The root_path method is made available by the call to the root method in config/
routes.rb. This simply outputs / when it’s called, providing a path to the root of your
application.
Running bin/cucumber features/viewing_tickets.feature again, you can see
this is all working:
1 scenario (1 passed)
18 steps (18 passed)
Your code expressly states that inside the TextMate 2 project, you should see only the
"Make it shiny!" ticket, and inside the Internet Explorer project, you should see only
the "Standards compliance" ticket. Both statements worked.
Time to make sure everything else is still working by running rake cucumber:ok
spec. You should see that everything is green:
10 scenarios (10 passed)
80 steps (80 passed)
# and
5 examples, 0 failures, 4 pending
Fantastic! Push!
git add .
git commit -m "Implemented features for displaying a list of relevant
tickets for projects and viewing particular tickets"
git push
Now you can see tickets just for a particular project, but what happens when a project
is deleted? The tickets for that project would not be deleted automatically. To implement
this behavior, you can pass some options to the has_many association, which will
delete the tickets when a project is deleted.
5.2.2 Culling tickets
When a project is deleted, its tickets become useless: they’re inaccessible because of
how you defined their routes. Therefore, when you delete a project, you should also
delete the tickets for that project, and you can do that by using the :dependent option
on the has_many association defined in your Project model.
This option has three choices that all act slightly differently from each other. The
first one is the :destroy value:
has_many :tickets, :dependent => :destroy
If you put this in your Project model, any time you call destroy on a Project object,
Rails iterates through each ticket for this project and calls destroy on them, then calls
any destroy callbacks (such as any has_manys in the Ticket model, which also have the
dependent option) 3 the ticket objects have on them, any destroy callbacks for those
objects, and so on. The problem is that if you have a large number of tickets, destroy
is called on each one, which will be slow.
3 Or any callback defined with after_destroy or before_destroy.
111