Ticket #480 (assigned enhancement)

Opened 4 years ago

Last modified 17 months ago

--show-sql option for migrate

Reported by: suor.web@… Owned by: andrew
Priority: minor Milestone: The Future
Component: commands Version: 0.7.1
Keywords: Cc:

Description

Somewhat similar to --db-dry-run, but outputs sql. Preferably, outputs orm queries too.
Anything besides sql can be output as sql comments.
Useful for debugging and sometimes replication.

For example, for Slony-I one can use:

./manage.py migrate --show-sql > /tmp/ddl.sql
slonik_execute_script [options] set# /tmp/ddl.sql

For now I use

./manage.py migrate --db-dry-run --verbosity=2 | perl -ne 'print if s/^\s*=\s(.*)\[\]$/$1/'

which is far from perfect.

Change History

comment:1 Changed 4 years ago by andrew

  • Status changed from new to assigned
  • Priority changed from major to minor
  • Version changed from unknown to 0.7.1
  • Milestone set to The Future

This has been asked for several times, by several different people, and the problem is that South doesn't know what SQL it's going to generate for some operations, especially things like index changes, since index names are not predictable and must be introspected from the database at runtime.

I plan to make this possible eventually, but it will never output _real_ SQL that you can run directly against a database, because that's literally impossible - the way to use South to make SQL has always been to run it against a copy of the database you're migrating, and record what it outputs. I'll take this ticket as a request for making that easier, and thus put it into The Future - however, you'll never see something that just spits out runnable SQL without having the database around.

comment:2 Changed 3 years ago by kamedov@…

I think this feature will be helpful if you working with custom field and don't always know what will be if you change it on other field. In this case this option help to analyse table changes.

comment:3 Changed 3 years ago by anonymous

Im not sure I see how this wouldn't be an easy feature to add. Surely you would introspect the DB in the normal way but when it comes to executing the migration, print out the SQL instead.

comment:4 Changed 2 years ago by ChrisP

I agree with anonymous, this feature is a must have, and I don't see any problems if it needs the database to do the introspection, that is fine, just print the SQL instead of running it!

comment:5 Changed 2 years ago by anonymous

++! How one can even commit some migration on production database for example without seeing it in plain SQL?

comment:6 follow-up: ↓ 9 Changed 2 years ago by andrew

Because, as I've said before, you need to run some of the migration to see the SQL the other parts will create (because index names, constraint names, etc. vary). I'm working on a solution that will make this possible, but if you want it for now you should run "migrate -v2 appname migrationname" against a COPY of the production database and it'll print the SQL

comment:7 Changed 2 years ago by kamedov@…

It's good, but workaround. If South can print SQL of running migrations, may be it isn't very complicated add ability to print sql without executing SQL?

comment:8 Changed 2 years ago by andrew

Nope, because you can't work out what names to put in the later SQL until you've run the earlier SQL, in general. As I said, I'm working on a fix to this, but it requires quite a bit of re-architecturing.

comment:9 in reply to: ↑ 6 Changed 18 months ago by bjb@…

Replying to andrew:

Because, as I've said before, you need to run some of the migration to see the SQL the other parts will create (because index names, constraint names, etc. vary). I'm working on a solution that will make this possible, but if you want it for now you should run "migrate -v2 appname migrationname" against a COPY of the production database and it'll print the SQL

This will only work if you want to see unapplied migrations.

I'd like to see the SQL for the migrations between <START> and <TARGET> and I want to be able to name both <START> and <TARGET> on the command line.

comment:10 Changed 17 months ago by Mark Jones <mark0978@…>

This would be good to see the sql for the current migration you want to run. I don't think you have to make it print all the migrations one after the other, doing it for ONE migration would be sufficient.

manage migrate --show-sql app

could print the sql for the current migration and then stop. No need to print them one after another. Typically I want to see what it is going to do on THIS migration, because something isn't migrating right. You already do the dry run, this is just printing what would be run on this one migration and that should be simple to do.

Note: See TracTickets for help on using tickets.