[Django] #25154: Migration errors don't contain enough information to debug properly
Django
------------------------------+--------------------
Reporter: brandonmoser | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------
After creating a migration, via `makemigrations`, I attempted to run
`sqlmigrate`, but received the following error. I have 3 migrations using
the object referenced. It would be helpful to add the exact migration
operation in the traceback. I think the migration traceback should, also,
show the model/table and column that is part of the error.
{{{
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-
packages/django/core/management/__init__.py", line 385, in
execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-
packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.7/dist-
packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.7/dist-
packages/django/core/management/commands/sqlmigrate.py", line 30, in
execute
return super(Command, self).execute(*args, **options)
File "/usr/local/lib/python2.7/dist-
packages/django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-
packages/django/core/management/commands/sqlmigrate.py", line 61, in
handle
sql_statements = executor.collect_sql(plan)
File "/usr/local/lib/python2.7/dist-
packages/django/db/migrations/executor.py", line 82, in collect_sql
migration.apply(project_state, schema_editor, collect_sql=True)
File "/usr/local/lib/python2.7/dist-
packages/django/db/migrations/migration.py", line 108, in apply
operation.database_forwards(self.app_label, schema_editor,
project_state, new_state)
File "/usr/local/lib/python2.7/dist-
packages/django/db/migrations/operations/fields.py", line 139, in
database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File "/usr/local/lib/python2.7/dist-
packages/django/db/backends/schema.py", line 460, in alter_field
return self._alter_many_to_many(model, old_field, new_field, strict)
File "/usr/local/lib/python2.7/dist-
packages/django/db/backends/schema.py", line 764, in _alter_many_to_many
new_field.rel.through._meta.get_field_by_name(new_field.m2m_reverse_field_name())[0],
File "/usr/local/lib/python2.7/dist-
packages/django/utils/functional.py", line 17, in _curried
return _curried_func(*(args + moreargs), **dict(kwargs, **morekwargs))
File "/usr/local/lib/python2.7/dist-
packages/django/db/models/fields/related.py", line 2224, in
_get_m2m_reverse_attr
return getattr(self, cache_attr)
AttributeError: 'VersionedManyToManyField' object has no attribute
'_m2m_reverse_name_cache'
}}}
'''Note''': I have posted this error to the CleanerVersion team due to the
exact error.
--
Ticket URL: <https://code.djangoproject.com/ticket/25154>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: brandonmoser | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.7
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 brandonmoser):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Old description:
New description:
'''Note''': The issue with the VersionedManyToManyField has a reported
issue with the CleanerVersion team and can be found
[https://github.com/swisscom/cleanerversion/issues/56 (here)].
--
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:1>
Django
Reporter: brandonmoser | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.7
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I am not sure if such a generic exception reporting mechanism is feasible
and/or practical to implement. Did you have any ideas about that?
I typically use pdb inside Django's source code to get the needed
information.
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:2>
Django
Reporter: brandonmoser | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.7
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by brandonmoser):
Replying to [comment:2 timgraham]:
> I am not sure if such a generic exception reporting mechanism is
feasible and/or practical to implement. Did you have any ideas about that?
>
> I typically use pdb inside Django's source code to get the needed
information.
As for exact implementation, I'm not sure. I'm pretty new to Python/Django
and haven't used pdb yet (I'll be digging into that next). I think the
frustration that I've seen in other tickets is that this is a failure
following a generated migration. If I had created a migration manually,
then I'm ok with obscure errors, since I should have a better
understanding of what I'm doing.
Here's what I would have liked to have seen in the error:
{{{
AttributeError: 'VersionedManyToManyField' object has no attribute
'_m2m_reverse_name_cache'. Seen on line 257 in
app_name/0003_auto_20150721_1018.py.
}}}
'''OR'''
{{{
AttributeError: 'VersionedManyToManyField' object has no attribute
'_m2m_reverse_name_cache' on `model_name.field`
}}}
Unfortunately for me, I've been fighting migrations for the last couple
days (due to some complicated changes) and have had to deal with errors
like this.
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:3>
Django
Reporter: brandonmoser | Owner: nobody
Type: New feature | Status: new
Component: Migrations | Version: 1.7
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by shaib):
I agree that migration stacktraces are missing references to the
migrations which caused them. Perhaps it can be helpful to add debugging
hints for migrations, e.g. "increase verbosity so you can tell which
migration caused the problem".
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:4>
Django
-------------------------------+------------------------------------
Reporter: brandonmoser | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------+------------------------------------
Changes (by timgraham):
* stage: Unreviewed => Accepted
* version: 1.7 => master
* component: Migrations => Documentation
* easy: 0 => 1
Comment:
Yes, I have used that technique. A section in docs/topics/migrations.txt
with tips on debugging migrations sounds good to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:5>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by MarkusH):
I've a patch laying around to output the exact operation and migration
that failed. Only struggling with the connection resets when a migration
failed, but that shouldn't be a problem to fix. Will push and link when
I've decent WiFi to rebase onto current master.
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:6>
Django
-------------------------------+------------------------------------
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by MarkusH):
Here you go: https://github.com/django/django/compare/master...MarkusH
:migration-traceback
Note the `raise NotImplementedError()` in
`test_debug_migrate_exception()`. I have no idea to fix the issues that
occur when you drop that line.
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:7>
Django
------------------------------+------------------------------------
Reporter: brandonmoser | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* component: Documentation => Migrations
* easy: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/25154#comment:8>