I think I am pissing into the wind to make migrations work at this
point.
Looking at
http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations
it appears that the problem that I am having is that postgresql can’t do
the drop_table part because of the foreign_key keys (constraints) which
requires ‘cascade’ as an option to drop some of the tables that have
other tables which include a column from the table I am attempting to
drop which would leave things in a mess.
I thought I would ask anyway…
Am I supposed to have each table migration in a separate file or should
they all be in the same file?
db/migration/0001_add_a_new_table
def self_up
create_table ‘foo’, :force => true do |t|
t.column …
end
create_table ‘foo2’, :force => true do |t|
t.column …
end
end
def self_down
drop_table :foo
drop_table :foo2
end
or multiple files?
db/migration/0001_add_foo
def self_up
create_table ‘foo’, :force => true do |t|
t.column …
end
end
def self_down
drop_table :foo
end
db/migration/0002_add_foo2
def self_up
create_table ‘foo2’, :force => true do |t|
t.column …
end
end
def self_down
drop_table :foo2
end
Craig
Am I supposed to have each table migration in a separate file or should
they all be in the same file?
There are no rules for this…but every logical change should occur in
one migration.
A migration can involve modifications to several tables, creating,
dropping whatever…
A migration should be considere atomic…
Foreign key constraints giving you problems?? Change the order of your
drops…or drop the constraints (in the database)
Mikkel B.
www.strongside.dk - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk - Buy Old Stuff!(DK)
On Wed, 2006-02-15 at 08:29 +0000, Mikkel B. wrote:
A migration should be considere atomic…
Foreign key constraints giving you problems?? Change the order of your
drops…or drop the constraints (in the database)
duh…of course - that may be difficult (the order) as there are a few
foreign keys already and I’m somewhat loathe to drop the foreign keys as
it’s entirely possible that this isn’t just for rails.
I’ll have to work on that but at least I know now that keeping the
various tables in one migration file does make sense - though there
isn’t any significant information in ‘rake migration’ --trace or
–verbose options and it took me quite some time to figure out that this
was a cascade thingy.
Thanks
Craig