Opened 9 years ago
Closed 9 years ago
#26335 closed New feature (needsinfo)
Show SQL if migration fails
Reported by: | Thomas Güttler | Owned by: | nobody |
---|---|---|---|
Component: | Migrations | Version: | 1.9 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I would like to see the SQL of a migrations.RunSQL('...') command in a migration.
For me this is very important, because failures during migrations on prod systems can make serious trouble.
I want to see the SQL immediately.
Here is the current output. The SQL is missing even if you use "-v 3".
foo_eins_d@aptguettler:~$ manage.py migrate --traceback Operations to perform: Synchronize unmigrated apps: ... Apply all migrations: ... Synchronizing apps without migrations: Creating tables... Running deferred SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying foo_eins.0002_auto_20160307_1559...Traceback (most recent call last): File "/home/foo_eins_d/src/djangotools/djangotools/bin/manage.py", line 29, in <module> main() File "/home/foo_eins_d/src/djangotools/djangotools/bin/manage.py", line 26, in main execute_from_command_line() File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 354, in execute_from_command_line utility.execute() File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 346, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/core/management/base.py", line 394, in run_from_argv self.execute(*args, **cmd_options) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/core/management/base.py", line 445, in execute output = self.handle(*args, **options) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 222, in handle executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 110, in migrate self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/migrations/executor.py", line 148, in apply_migration state = migration.apply(state, schema_editor) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/backends/base/schema.py", line 93, in __exit__ self.atomic.__exit__(exc_type, exc_value, traceback) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/transaction.py", line 225, in __exit__ connection.commit() File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 173, in commit self._commit() File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 142, in _commit return self.connection.commit() File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/utils.py", line 98, in __exit__ six.reraise(dj_exc_type, dj_exc_value, traceback) File "/home/foo_eins_d/local/lib/python2.7/site-packages/django/db/backends/base/base.py", line 142, in _commit return self.connection.commit() django.db.utils.IntegrityError: update or delete on table "foo_table" violates foreign key constraint "foo_table_18a7d05da409f61d_fk_foo_table_id" on table "foo_other_table" DETAIL: Key (id)=(10002) is still referenced from table "foo_other_table".
What do you think?
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
My above problem is tricky: The exception does not happen during RunSQL(), it happens at the end during commit()
.
Django can not identify the migration operation which lead to the failure ...
comment:3 by , 9 years ago
Component: | Database layer (models, ORM) → Migrations |
---|---|
Resolution: | → needsinfo |
Status: | new → closed |
Type: | Uncategorized → New feature |
Right. Well, if you can provide a solution, feel free to do so.
I'm not sure an implementation is feasible. A possible solution would be to configure your
LOGGING
setting to log all queries. Presumably you'd want a separate settings file from the one you use to run your server because logging all queries in that case probably wouldn't be desirable. Some databases can also log failing queries.