Migrations - safeDown() content

I’ve just started using migrations for my new project. Everything seems to be great but the content of methods safeDown() or down() is confusing me.

In the guide you’ve written:

This is in general of course an important advice, but the example is misleading. Why should I even care to write a code for deleting a row from a table, when the table is about to be dropped anyway?

The same applies for removing indexes. If I create a migration from the command line, there is a code for removing indexes before dropping the table. Why? The index is of course removed, when the table is dropped.

I believe the same applies for the foreign keys as well – they don’t need to be removed manually, if I keep the right order of dropping tables - the last tables goes first.

Am I missing something? Thanks for your advice.

Any idea, please?

FKs need to be removed before dropping the table because they are preventing table drops. You’re right about indexes.

I usually create tables, then create indexes (indices?) and lastly foreign keys; in 3 separate migrations.

I also create corresponding commands in the down/safedown functions to remove whatever is created in the up/safeup functions.

Why not?

It’s “good practice”!

I also make a habit of making sure that I can migrate up and down at any point in time.

Then you don’t have to worry about which table to drop first.

Is it possible, that your statement is true only for Mysql? I’ve just tried to create a test table with fkey restricted for delete/update, insert a linked entry and then drop the table, and everything worked well in Postgre 9.x. I suppose, that I should use dropping the fkeys in case, a different db then PG is used.

[/size]

Is it really a good practise? The table is complete only with all indexes and foreign keys. I thought that one migration should solve one whole “entity”, which table without indexes and keys isn’t.

I don’t see here any advantage.

I do not. The migrations solves this for me. The later one runs first when doing reverting.

Yes, it could be true for particular DB engines only.

Ondrej: Who writes the migrations for you? A mystical imp with magical powers ?

Why are you asking? It’s true that I’m small and ugly, but I don’t have any magical powers which I’m aware of.

I am referring to this comment of yours:

Seems to imply that someone other than you wrote the migrations

Anyway: I suspect that we agree on most things.

I prefer to be in more control that you, especially when my db schema is a bit involved and thus can’t be written in one migration.

OH, I see That’s probably because of my level of English.

Thank you for your answers though.