Topic: Foreign key contraint whoes

Following the recipe in Agile Web Development with Rails (2nd ed.), I added foreign key constraints to my database using a migration with code that looks like so in self.up:

execute "alter table line_items
           add constraint fk_line_item_products
           foreign key (product_id) references products(id)"
execute "alter table line_items
           add constraint fk_line_item_orders
           foreign key (order_id) references orders(id)"

And, being the good developer, I of course wanted unit tests that confirmed that cascading deletes were working.  Here is the rub:  rake test   creates the database from schema.rb which, doesn't get the execute lines.  sad  I haven't gotten that far yet but I think rake deploy will also use schema.rb.  I went to a pragmatic studio session where one of the authors said that migrations weren't typically used to deploy to test and production. 

So I ask, what good are migrations if they can't be used to migrate from dev to test to production?   It seems like migrations are a subversion (pardon the pun) of source control (once checked it, never edited, create a new one).  It seems to me that it would just be easier to change db:migrate to use schema.rb and manually keep schema.rb up to date and checked in.  When you need to go back to an older version, just pull schema.rb from source control apply it to a new db and write a quick script to get/map data from the newer test database.

But maybe that's just the old school in me talking..  I'm curious if anyone has done something similar to what I suggest with rails - I mean, I know we use to do it all the time in non RoR apps with little frustration.

-bryan