#23244 closed Bug (fixed)
changing a ForeignKey to CharField breaks migrations
| Reported by: | Owned by: | nobody | |
|---|---|---|---|
| Component: | Migrations | Version: | 1.7-rc-2 |
| Severity: | Release blocker | 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
See my example project at:
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
Change History (4)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
My workaround was to rename the field to something temporary like
phone_number_temp, then create a migration, rename it back tophone_numberand create another migration.Perhaps that's what
makemigrationsshould do automatically