I'm a total noob to RoR so I've started my app from scratch countless
times. As I figure out what I need in my DB I've been adding it to a
file 001_build.rb - so when i restart AGAIN i just run the migration
and i'm back up and running rather quickly. Is this a BAD idea?
It hasn't been an issue until today when I ran my first
scaffold_resource - which ran fine until i pulled it up in the browser
and it had no clue that my db was already up and running with all the
tables and fields I needed.
I can run the scaffold_resource with all the field names and types,
but i have NO clue how to force the use of a foreign key like i've
been using in my migration file. This is what I've been using:
I'm a total noob to RoR so I've started my app from scratch countless
times. As I figure out what I need in my DB I've been adding it to a
file 001_build.rb - so when i restart AGAIN i just run the migration
and i'm back up and running rather quickly. Is this a BAD idea?
Migrations are intended to be cumulative, so there's really no reason to keep everything in the first migration file. When you run rake db:migrate, all of the necessary migrations are run to bring the database up to date. One reason *not* to put it all in one large file is that it makes properly defining the down method (for undoing a migration) more complicated.
I can run the scaffold_resource with all the field names and types,
but i have NO clue how to force the use of a foreign key like i've
been using in my migration file. This is what I've been using:
Thanks for the insight Michael! I can see how the down method could
help down the road! I'll quit using the one LARGE migration file.
On that note, does anyone know how to require a foreign key in the
generate command? I currently have it in the rake file, but I don't
know how to do the same thing from the command line.