Slowing down migration in Django
I have a new field to add to my db. So I say
python manage.py makemigrations
which creates correctly kernel/migrations/0003_auto_20150726_1911.py
. I check the content and everything looks good.
I say
python manage.py migrate
and I'm less happy. The file kernel/migrations/0002_auto_20150707_1459.py
that adds the field date_of_birth
to the table userprofile
fails. Though I'm pretty sure the migration applies. And so the 0003 migration never gets applied.
This is production. :( I'm not really sure what to do to apply 0003 and not django for the hose. Suggestions?
For the rest, this does document support:
Migrations
╭╴ (master=) [virt]╶╮
╰ [T] django@beta13:migrations $ cat 0002_auto_20150707_1459.py
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations
class Migration(migrations.Migration):
dependencies = [
('kernel', '0001_initial'),
]
operations = [
migrations.AlterField(
model_name='userprofile',
name='date_of_birth',
field=models.DateField(null=True, blank=True),
),
]
╭╴ (master=) [virt]╶╮
╰ [T] django@beta13:migrations $ cat 0003_auto_20150726_1911.py
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations
from django.conf import settings
class Migration(migrations.Migration):
dependencies = [
migrations.swappable_dependency(settings.AUTH_USER_MODEL),
('kernel', '0002_auto_20150707_1459'),
]
operations = [
migrations.AddField(
model_name='trippending',
name='requesting_user',
field=models.ForeignKey(default=1, related_name='trippending_requesting', to=settings.AUTH_USER_MODEL),
preserve_default=False,
),
migrations.AddField(
model_name='userprofile',
name='can_see_pending_trips',
field=models.BooleanField(default=False),
),
]
╭╴ (master=) [virt]╶╮
╰ [T] django@beta13:migrations $
Mistake
(The site is in French, but I think the error is all the same.)
╭╴ (master %=) [virt]╶╮
╰ [T] django@beta13:django $ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: staticfiles, messages, admindocs
Apply all migrations: admin, sessions, custom_user, auth, kernel, contenttypes, registration, sites
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying kernel.0002_auto_20150707_1459...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/src/django/venv/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 147, in apply_migration
state = migration.apply(state, schema_editor)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/migration.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/src/django/venv/lib/python3.4/site-packages/django/db/migrations/operations/fields.py", line 201, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 484, in alter_field
old_db_params, new_db_params, strict)
File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 571, in _alter_field
old_default = self.effective_default(old_field)
File "/src/django/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 211, in effective_default
default = field.get_db_prep_save(default, self.connection)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 710, in get_db_prep_save
prepared=False)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1322, in get_db_prep_value
value = self.get_prep_value(value)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1317, in get_prep_value
return self.to_python(value)
File "/src/django/venv/lib/python3.4/site-packages/django/db/models/fields/__init__.py", line 1287, in to_python
params={'value': value},
django.core.exceptions.ValidationError: ["Le format de date de la valeur «\xa0\xa0» n'est pas valide. Le format correct est AAAA-MM-JJ."]
╭╴ (master %=) [virt]╶╮
╰ 1,[T] django@beta13:django $
Data
I checked with postgres expecting to find something bad. But everything looks fine.
mydb=# select date_of_birth from kernel_userprofile;
date_of_birth
---------------
2018-10-23
1972-05-31
1978-10-21
2008-12-29
1967-08-26
2015-07-26
(6 rows)
mydb=#
source to share
For the community, the issue was django_migrations
not updated with help 0002_auto_20150707_1459
, although the migration was actually applied on table
as stated in the post.
The solution was to insert a new row into a table django_migrations
with data like below, so the migration 0002
was skipped.
INSERT INTO DJANGO_MGRATIONS ('app', 'name', 'applied') VALUES ('appname', '0002_auto_20150707_1459', '2015-07-07 00:00')
Skipping migration should be done with extreme care, so check all the details before skipping.
source to share
For those who find this post: I just helped a colleague to debug a similar problem (same error message), in which case the source of the problem was trying to give the DateField a default value u""
(which has a course invalid for date) instead None
.
Actually part of the fun was that the previous migration (which created the model) already had this wrong option by default but still ran without issue, the error only appears when trying to change the field anyway.
The fix requires editing the previous migration to set it to the default, because Django uses the previous migration schema description to get the previous default.
source to share