[Django] #22371: AttributeError during replaying/loading of migration: 'module' object has no attribute 'RemovedModel'
Django
no attribute 'RemovedModel'
----------------------------+------------------------
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-beta-1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+------------------------
I am getting a `AttributeError` when the existing migrations get loaded,
but the model has been removed.
It looks like the migrations would have to refer to the `to`, `through`
and possibly other arguments by string?!
The migration:
{{{
operations = [
migrations.AddField(
model_name='model',
name='country_of_origin',
field=taggit.managers.TaggableManager(to=app.models.CountryOfOriginTag,
through=app.models.TaggedCountryOfOrigin, blank=True, help_text=u'A comma-
separated list of tags.', verbose_name=u'Country of origin'),
preserve_default=True,
),
]
}}}
{{{
Traceback (most recent call last):
File "/home/user/.virtualenvs/project/bin/manage.py", line 62, in
<module>
execute_from_command_line(sys.argv)
File "…/django/django/core/management/__init__.py", line 427, in
execute_from_command_line
utility.execute()
File "…/django/django/core/management/__init__.py", line 419, in
execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "…/django/django/core/management/base.py", line 288, in
run_from_argv
self.execute(*args, **options.__dict__)
File "…/django/django/core/management/base.py", line 337, in execute
output = self.handle(*args, **options)
File "…/django/django/core/management/commands/makemigrations.py",
line 56, in handle
loader.build_graph(ignore_unmigrated=True)
File "…/django/django/db/migrations/loader.py", line 145, in
build_graph
self.load_disk()
File "…/django/django/db/migrations/loader.py", line 103, in
load_disk
migration_module = import_module("%s.%s" % (module_name,
migration_name))
File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
File "…/project/app/migrations/0006_movie_country_of_origin.py",
line 7, in <module>
class Migration(migrations.Migration):
File "…/project/app/migrations/0006_movie_country_of_origin.py",
line 17, in Migration
field=taggit.managers.TaggableManager(to=app.models.CountryOfOriginTag,
through=app.models.TaggedCountryOfOrigin, blank=True, help_text=u'A comma-
separated list of tags.', verbose_name=u'Country of origin'),
AttributeError: 'module' object has no attribute 'CountryOfOriginTag'
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22371>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
no attribute 'RemovedModel'
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-beta-1
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by loic84):
* cc: loic@… (added)
* needs_better_patch: => 0
* has_patch: 0 => 1
* needs_tests: => 0
* needs_docs: => 0
Comment:
Hi @blueyed, could you check if
https://github.com/loic/django/compare/ticket22371 works?
I'm not convinced serializing models automatically is the best approach
though, it probably doesn't work well with swappable models.
Maybe the right fix is to have taggit's deconstruct do a little more work.
--
Ticket URL: <https://code.djangoproject.com/ticket/22371#comment:1>
Django
no attribute 'RemovedModel'
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-beta-1
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by blueyed):
Thanks!
Unfortunately I've worked around this already, and have no time currently
to get back to the old state.
--
Ticket URL: <https://code.djangoproject.com/ticket/22371#comment:2>
Django
no attribute 'RemovedModel'
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-beta-1
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* stage: Unreviewed => Accepted
Comment:
If we don't accept Loic's patch, then maybe some documentation about this
situation would help?
--
Ticket URL: <https://code.djangoproject.com/ticket/22371#comment:3>
Django
no attribute 'RemovedModel'
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-beta-1
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timo):
Loic, any thoughts on if we should do anything here?
--
Ticket URL: <https://code.djangoproject.com/ticket/22371#comment:4>
Django
no attribute 'RemovedModel'
Reporter: blueyed | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.7-beta-1
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by loic84):
* severity: Normal => Release blocker
Comment:
I'm not completely convinced this is needed, `TaggableManager` could
provide a `deconstruct` method and handle serializing `Model` objects.
That said if models as arguments are common enough we could support them
out of the box.
I don't think a documentation fix is warranted, we already document what
types are supported by the serializer.
I'd let Andrew decide if we should go with the proposed fix or wontfix the
ticket, it's just a matter of making a decision so bumping the ticket to
Release Blocker.
--
Ticket URL: <https://code.djangoproject.com/ticket/22371#comment:5>
Django
no attribute 'RemovedModel'
Reporter: blueyed | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.7-beta-1
Severity: Release blocker | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by andrewgodwin):
* status: new => closed
* resolution: => wontfix
Comment:
Yep, I'm WONTFIXing this. Taggable needs to return those as strings and do
the lookups in the app registry itself (if it doesn't already); migrations
won't freeze model references, down that path madness lies.
Note for taggable people: The apps registry you want to use is the one on
the model, i.e. `model._meta.apps` - that way model versioning will work
correctly.
--
Ticket URL: <https://code.djangoproject.com/ticket/22371#comment:6>