Problems with --dry-run

[zeelot]

On any project that deploys to a live site with database values, a migration needs to copy and move data around in the database. --dry-run would not be able to run any of the select queries which cripples the feature quite a bit. Here is a simple example:

Our project is live and has data in it, users upload profile pictures and the url gets saved to users.profile_picture. In the next version of the site, we want to move all images to a files table so I am creating the table and need to change users.profile_picture to users.profile_picture_id. The migration process would look something like this (probably over multiple migration files):

• Create Table files
• Create Column users.profile_picture_id
• Find all the user profiles
• Copy the profile pictures to the files table
• Update the users.profile_picture_id columns
• Drop Column users.profile_picture
• Add Foreign Keys and Constraints

[BRMatt]

So basically you'd like SELECT queries to be proxied through to the real database connection?

One problem I see is that if later migrations run SQL queries which depend on changes made in preceding migrations - the queries would obviously error out.

[zeelot]

I don't think dry runs are possible with the current implementation at all. Making a proxy for SELECT queries would not be good enough. I don't actually know the solution to this issue, I'm simply stating that the current implementation is clever but not good enough in my opinion.

[zeelot]

I was informed that this kind of stuff should be done in multiple steps, and the moving of data should be done in a task other than migrations. In which case, we can close this issue. Migrations should be strictly SQL (table altering)

[BRMatt]

Agreed