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.
Thank you.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.