[Django] #26335: Show SQL if migration fails
Django
----------------------------------------------+--------------------
Reporter: guettli | Owner: nobody
Type: Uncategorized | Status: new
Component: Database layer (models, ORM) | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------------------+--------------------
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/26335>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: guettli | Owner: nobody
Type: Uncategorized | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
I'm not sure an implementation is feasible. A possible solution would be
to configure your `LOGGING` setting to
[https://docs.djangoproject.com/en/dev/topics/logging/#django-db-backends
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26335#comment:1>
Django
Reporter: guettli | Owner: nobody
Type: Uncategorized | Status: new
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by guettli):
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
...
--
Ticket URL: <https://code.djangoproject.com/ticket/26335#comment:2>
Django
Reporter: guettli | Owner: nobody
Type: New feature | Status: closed
Component: Migrations | Version: 1.9
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* component: Database layer (models, ORM) => Migrations
* type: Uncategorized => New feature
* resolution: => needsinfo
Comment:
Right. Well, if you can provide a solution, feel free to do so.
--
Ticket URL: <https://code.djangoproject.com/ticket/26335#comment:3>