https://github.com/pjrobertson/django_migrations_bug
Basically, I'd decided that instead of using another model to represent a
specific field on my 'parent' model, I'd just use a plain old charfield.
Check out my repo, and run `./manage.py migrate migr` and you'll see the
problem. For reference, the full trace is here:
{{{
Applying migr.0002_auto_20140806_1432...Traceback (most recent call
last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/core/management/__init__.py", line 385, in
execute_from_command_line
utility.execute()
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/core/management/base.py", line 337, in execute
output = self.handle(*args, **options)
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/core/management/commands/migrate.py", line 160, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/db/migrations/executor.py", line 63, in migrate
self.apply_migration(migration, fake=fake)
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/db/migrations/executor.py", line 97, in apply_migration
migration.apply(project_state, schema_editor)
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/db/migrations/migration.py", line 107, in apply
operation.database_forwards(self.app_label, schema_editor,
project_state, new_state)
File "/Users/patrick/.virtualenvs/migr/lib/python2.7/site-
packages/django/db/migrations/operations/fields.py", line 129, in
database_forwards
elif isinstance(to_field.rel.to, six.string_types):
AttributeError: 'NoneType' object has no attribute 'to'
}}}
In order to get the example project into its current state I did the
following:
{{{
$ django-admin.py startproject migr
$ # add 'migr' to INSTALLED_APPS
$ # created models.py with the 'BEFORE' (see commented code in models.py)
code
$ ./manage.py makemigrations migr
$ ./manage.py migrate
$ # updated models.py to how it is in the repo (a char field for
'phone_number')
$ ./manage.py makemigrations migr
$ ./manage.py migrate
$ # EXCEPTION
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23244>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
My workaround was to rename the field to something temporary like
`phone_number_temp`, then create a migration, rename it back to
`phone_number` and create another migration.
Perhaps that's what `makemigrations` should do automatically
--
Ticket URL: <https://code.djangoproject.com/ticket/23244#comment:1>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"dfe86449c9951824dfa95d44af36ef1d8e578bdc"]:
{{{
#!CommitTicketReference repository=""
revision="dfe86449c9951824dfa95d44af36ef1d8e578bdc"
Fixed #23244: Error altering FK to non-FK in migrations
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23244#comment:2>
Comment (by Andrew Godwin <andrew@…>):
In [changeset:"0e69af51b1557ebe3ce93fe31498f3fa797b4b83"]:
{{{
#!CommitTicketReference repository=""
revision="0e69af51b1557ebe3ce93fe31498f3fa797b4b83"
[1.7.x] Fixed #23244: Error altering FK to non-FK in migrations
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23244#comment:3>
Comment (by django@…):
That was quick. Cheers Andrew :)
--
Ticket URL: <https://code.djangoproject.com/ticket/23244#comment:4>