I have a new field to add to my db. So I say
python manage.py makemigrations
which correctly creates kernel/migrations/0003_auto_20150726_1911.py. I inspect the contents and all looks good.
I say
python manage.py migrate
and I am less happy. The file kernel/migrations/0002_auto_20150707_1459.py, which adds field date_of_birth to table userprofile, fails. Even though I'm pretty sure that migration is applied. And so migration 0003 is never applied.
This is production. :(
I'm not at all sure what to do in order to apply 0003 and not hose django. Suggestions?
The rest of this is supporting docs:
The 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 $
The error
(The site runs in French, but I think the error is clear anyway.)
╭╴ (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 $
The data
I checked with postgres, expecting to find something amiss. But all 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=#
For the community, the issue was django_migrations table was not updated with 0002_auto_20150707_1459 even though the migration was actually applied on table as mentioned in the post.
The solution was to insert a new row in django_migrations table with data like below so migration 0002 was skipped.
INSERT INTO DJANGO_MGRATIONS ('app', 'name', 'applied') VALUES ('appname', '0002_auto_20150707_1459', '2015-07-07 00:00')
Skipping migration must be done with extreme caution, hence check all details before skipping.
Same trouble happend, but without any logs
At first I determined what app was a problem, by running
python manage.py migrate app_name
for every django app
after that I check migrations for app by running
python manage.py showmigrations app_name
And marked first uncompleted migration as completed by running
python manage.py migrate --fake app_name migration_name
※ about fake
And that was a solution in my case
For anyone finding this post: I just helped a coworker debug a similar problem (same error message), and in this case the source of the problem was trying to give the DateField a default value of u"" (which is of course invalid for a date) instead of None.
Actually part of the fun was that the previous migration (which created the model) already had this wrong default but still ran seamlessly, the error only appearing when trying to alter the field in any way.
The fix required editing the previous migration to set the sane default value, since Django uses the previous migration's schema description to get the previous default value.
Related
I have a development database I was working on and I had issues with the migrations taking for adding a foreignkey field. I ended up having to blow away the database after clearing my migrations folder out and redoing it. So now I have one migration file...
The problem is, I pulled code to my test server, and now that database is VERY out of sync (it's not, django thinks it is. It really just needs a table added and a field). Though running make migrations breaks as the migration folder I had pushed was clear of all but one migration and does not jive with the migration folder on the test server.
Any ideas as to how I can reconcile this, it is my test data so blowing away the database here and starting new isn't an issue, but this will be a huge issue again when I push to production (and cannot blow away that database). Maybe dump the data/database using pg_dump, blow away the database, run migrations and load the data back via the dump file?
EDIT:
I did try to create my own migration manually since I was in a state where makemigrations said nothing new was done. My migration file:
The error it gives me (no idea what this is telling me)
Operations to perform:
Apply all migrations: filer, sessions, admin, auth, contenttypes, swsite, registration, easy_thumbnails
Running migrations:
Rendering model states... DONE
Applying swsite.0001_initial... OK
Applying swsite.0002_auto_20170302_0841...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/usr/lib64/python2.7/site-packages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib64/python2.7/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/usr/lib64/python2.7/site-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 92, in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 121, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/migration.py", line 115, in apply
operation.state_forwards(self.app_label, project_state)
File "/usr/lib64/python2.7/site-packages/django/db/migrations/operations/fields.py", line 50, in state_forwards
state.models[app_label, self.model_name_lower].fields.append((self.name, field))
KeyError: (u'swsite', u'cesiumentity')
The migration:
# -*- coding: utf-8 -*-
# Generated by Django 1.9.6 on 2017-03-02 15:41
from __future__ import unicode_literals
from django.db import migrations, models
import django.contrib.gis.db.models.fields
import django.db.models.deletion
class Migration(migrations.Migration):
dependencies = [
('swsite', '0001_initial'),
]
operations = [
migrations.CreateModel(
name='ZoneEntity',
fields=[
('zone_number', models.CharField(max_length=100, primary_key=True, serialize=False)),
('mpoly', django.contrib.gis.db.models.fields.PolygonField(srid=4326)),
('created_at', models.DateField(auto_now_add=True)),
('updated_at', models.DateField(auto_now=True)),
],
),
migrations.AddField(
model_name='cesiumentity',
name='zone_id',
field=models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.CASCADE, to='swsite.ZoneEntity'),
),
]
If this is something you can do manually (add one field and one table), you can set the migrations as completed in the migration table (either all of them, or just the ones that are causing issues).
This might help you out:
https://www.algotech.solutions/blog/python/django-migrations-and-how-to-manage-conflicts/
As you are the single developer for the project, python manage.py migrate should be fine if you are pushing migrations in the git repo.
Or you can ignore migrations folder by adding it to .gitignore and run python manage.py makemigrations on test server every time db is modified and finally u can execute python manage.py migrate to reflect changes in the db.
models.py
class Stop(models.Model):
idn = models.PositiveIntegerField(primary_key=True, unique=True)
label = models.CharField(null=False, blank=False, max_length=512)
coor_x = models.FloatField()
coor_y = models.FloatField()
buses = models.ManyToManyField(Bus)
latest_query_datetime = models.DateTimeField(default=datetime(2000, 1, 1, 0, 0, 0))
latest_query_data = JSONField(default={})
class Meta:
ordering = ["label"]
def __str__(self):
return self.label
When I run:
python3 manage.py makemigrations && python3 manage.py migrate
It raises a ProgrammingError saying that jsonb datatype does not exist:
Migrations for 'rest':
0007_auto_20160612_1301.py:
- Alter field latest_query_data on stop
Operations to perform:
Apply all migrations: contenttypes, rest, auth, sessions, admin
Running migrations:
Rendering model states... DONE
Applying rest.0005_auto_20160612_1237...Traceback (most recent call last):
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: type "jsonb" does not exist
LINE 1: ... TABLE "rest_stop" ADD COLUMN "latest_query_data" jsonb DEFA...
^
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/migrations/executor.py", line 92, in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/migrations/executor.py", line 121, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/migrations/migration.py", line 123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/migrations/operations/fields.py", line 62, in database_forwards
field,
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/backends/base/schema.py", line 396, in add_field
self.execute(sql, params)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/backends/base/schema.py", line 110, in execute
cursor.execute(sql, params)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/utils.py", line 95, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/utils/six.py", line 685, in reraise
raise value.with_traceback(tb)
File "/home/erayerdin/.venv/eshot-api/lib/python3.5/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: type "jsonb" does not exist
LINE 1: ... TABLE "rest_stop" ADD COLUMN "latest_query_data" jsonb DEFA...
I use PostgreSQL to use JSONField and update it when a user requests a view. If I do not use default={}, it tells me to make one.
Further Analysis
I changed latest_query_data field to TextField so that I can store as string and convert to dict when I need. However, this also raised the same error.
Environment
django 1.9.6
psycopg 2.6.1
According to the Django docs, JSONField requires PostgreSQL ≥ 9.4 and Psycopg2 ≥ 2.5.4
What PostgreSQL version are you using?
See https://docs.djangoproject.com/en/dev/ref/contrib/postgres/fields/#django.contrib.postgres.fields.JSONField
Ubuntu 14.04 repositories contain only 9.3 version. You can review this to upgrade your version.
Based on the Anonymous comment, I found the following to work:
from django.contrib.postgres import fields
class OldJSONField(fields.JSONField):
def db_type(self, connection):
return 'json'
class Stop(models.Model):
...
latest_query_data = OldJSONField(default=dict)
...
If you are getting this error and you have installed Postgres > 9.4 then I would check that you aren't connecting to an older version of Postgres that is also installed on your instance.
To confirm what you are connecting to from Django you can use psycopg2 from the shell:
import psycopg2
conn = psycopg2.connect("dbname=<your database> user=<your user> password=<your password>")
cur = conn.cursor()
cur.execute("SELECT Version();")
cur.fetchone()
Make sure the version here is > 9.4. If not you probably have a couple of versions installed and your service configuration is pointing at the other version.
With older versions of PostgreSQL for example "PostgreSQL9.2.x",
We can use an alternative as
from jsonfield import JSONField
instead of:
from django.contrib.postgres.fields import JSONField
for example:
from django.db import models
from jsonfield import JSONField
class MyModel(models.Model):
json = JSONField()
Can install as:
pip install jsonfield
Check this out:
Add support for PostgreSQL 9.2+'s native json type. #32
This solution is especially good for some limited edition versions. For example,
on VPS & Cpanel that supports postgresql9.2 by default
more details!, see"rpkilby-jsonfield"
So, it seems a bug on psycopg2 or django, I will post an issue on both repositories. This is how I've solved (at least, ProgrammingError) the problem.
Change JSONField to TextField.
Flush your database.
Beware! This operation will erase all the data but the structure in your database.
Remove all migrations folder in all of your apps.
Run python3 manage.py makemigrations && python3 manage.py migrate in all of your apps.
Run python manage.py makemigrations <appname> && python3 manage.py migrate <appname> for each app you have.
Use built-in json module to convert between str and dict.
However, remember, this solution requires so much effort if you want to filter a QuerySet of a model. I do not recommend it, but there was no other solution to get rid of this error and all I needed to do was to save data and represent it.
! This answer will be accepted as default if there will not occur any other better solution in 48 hours.
I'm trying to run a migration for my Django project, but I'm getting the error:
AttributeError: 'ManyToManyField' object has no attribute 'm2m_reverse_field_name'
I when I ran make migrations on all my apps, I didn't get any errors. It's only when I try to actually migrate. I can't tell from the traceback information which model is creating the problem, or even which app. I've looked at my models, and I don't see anything that pops out at me.
Here is the stack trace:
Operations to perform:
Apply all migrations: admin, sessions, case_manager, file_manager, auth, contenttypes, tasks, people_and_property
Running migrations:
Rendering model states... DONE
Applying file_manager.0006_auto_20160109_1536...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 350, in execute_from_command_line
utility.execute()
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 342, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 92, in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 121, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/db/migrations/migration.py", line 123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/home/mint/Python_Projects/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 "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/db/backends/base/schema.py", line 467, in alter_field
return self._alter_many_to_many(model, old_field, new_field, strict)
File "/home/mint/Python_Projects/venv/lib/python3.4/site-packages/django/db/backends/sqlite3/schema.py", line 274, in _alter_many_to_many
old_field.remote_field.through._meta.get_field(old_field.m2m_reverse_field_name()),
AttributeError: 'ManyToManyField' object has no attribute 'm2m_reverse_field_name'
How do I figure out which model is the problem? What should I look for?
You have to make sure that the model you are creating the 'ManyToManyField' is already created in the database.
You can do that by adding as a dependency the migration where the model is created to your migration in which you alter the field:
Scenario 1: You alter the field to 'ManyToManyField' with a model from other app
class Migration(migrations.Migration):
dependencies = [
..........
('[app]', '__first__'),
]
operations = [
.........
]
Scenario 2: You create a 'ManyToManyField' and the model you are referring to is in the same file:
class Migration(migrations.Migration):
dependencies = [
..........
]
operations = [
.........
# Make sure the model you are making the reference with is before the ManyToManyField
migrations.CreateModel(...) ,
migrations.AlterField/CreateField(...)
]
I ran into the same problem, but I don’t know if for the same reasons. Luckily I don’t have any important data in the system, so I just changed the migration as follows – but note that this deletes all data in these columns!
Before:
operations = [
migrations.AlterField(
model_name='resource',
name='authors',
field=models.ManyToManyField(related_name='resources_authored', to='api.Person'),
),
migrations.AlterField(
model_name='resource',
name='editors',
field=models.ManyToManyField(blank=True, related_name='resources_edited', to='api.Person'),
),
]
After:
operations = [
migrations.RemoveField(
model_name='resource',
name='authors',
),
migrations.RemoveField(
model_name='resource',
name='editors',
),
migrations.AddField(
model_name='resource',
name='authors',
field=models.ManyToManyField(related_name='resources_authored', to='api.Person'),
),
migrations.AddField(
model_name='resource',
name='editors',
field=models.ManyToManyField(blank=True, related_name='resources_edited', to='api.Person'),
),
]
While the altering failed for mysterious reasons, removing and recreating the fields worked.
One of the reason might be your api.Person model migrations might not have run before the one in which it is referenced(in your example it is file_manager.0006_auto_20160109_1536). So make sure api.Person migrations are run before, by adding them in the dependencies of file_manager.0006_auto_20160109_1536.
I had the same problem when I tried to rename a table which was referenced with a many to many fields.
I resolved it this way:
- dumped the manytomany relationship data into a file
- removed the manytomany field and migrated
- renamed the table and migrated
- added the manytomany field back and migrated and loaded the relationships from the dump
I also had the same problem, but the way that I fixed it, is the following steps:
Nota: You will lose data from that ManyToManyField
python manage.py makemigrations app_name
python manage.py migrate app_name --fake
Don't forget the --fake
After that.
I removed (or just comment the line) the ManyToMany field, and then makemigrations app_name, migrate app_name.
At this step you have this column from your database cleared, what you need to do now is to re add the ManyToManyField, so when you makemigrations app_name & migrate app_name again.
You server can run perfectly
It's not the best, but it worked for me.
hope it will help !
My problem came with changing a field from a choices field to a manytomanyfield.
If you do this and keep the same name, then you'll have issues.
I followed Denis Drescher:
Basically go through your migration files and check what django is doing with these fields.
If django is doing migrations.AlterField for the field which was a choices field and is now a manytomanyfield, change it to
migrations.RemoveField and then Migrations.AddField
I had no meaningful data as yet, so I deleted the database(db.sqlite3) and all migrations(0001,0002 etc)
Simply check if you renamed model-related attributes or anthing related to the model in the admin before you drop the db.
Actually it worked for me.
In a Django 1.8 project, I have a migration that worked fine, when it had the following code:
# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import migrations
from django.conf import settings
def update_site_forward(apps, schema_editor):
"""Add group osmaxx."""
Group = apps.get_model("auth", "Group")
Group.objects.create(name=settings.OSMAXX_FRONTEND_USER_GROUP)
def update_site_backward(apps, schema_editor):
"""Revert add group osmaxx."""
Group = apps.get_model("auth", "Group")
Group.objects.get(name=settings.OSMAXX_FRONTEND_USER_GROUP).delete()
class Migration(migrations.Migration):
dependencies = [
('auth', '0001_initial'),
]
operations = [
migrations.RunPython(update_site_forward, update_site_backward),
]
This group is created in a migration, because it shall be available in all installations of the web app. To make it more useful, I wanted to also give it a default permission, so I changed update_site_forward to:
def update_site_forward(apps, schema_editor):
"""Add group osmaxx."""
Group = apps.get_model("auth", "Group")
Permission = apps.get_model("auth", "Permission")
ContentType = apps.get_model("contenttypes", "ContentType")
ExtractionOrder = apps.get_model("excerptexport", "ExtractionOrder")
group = Group.objects.create(name=settings.OSMAXX_FRONTEND_USER_GROUP)
content_type = ContentType.objects.get_for_model(ExtractionOrder)
permission = Permission.objects.get(codename='add_extractionorder',
content_type=content_type) # line 16
group.permissions.add(permission)
and Migration.dependencies to:
dependencies = [
('contenttypes', '0002_remove_content_type_name'),
('excerptexport', '0001_initial'),
('auth', '0001_initial'),
]
While applying the migration (after first reverting it) (python3 manage.py migrate auth 0001 && python3 managy.py migrate) worked, migrating a newly created PostgreSQL database with this and all other migrations (python3 manage.py migrate) fails:
Operations to perform:
Synchronize unmigrated apps: debug_toolbar, django_extensions, messages, humanize, social_auth, kombu_transport_django, staticfiles
Apply all migrations: excerptexport, admin, sites, contenttypes, sessions, default, stored_messages, auth
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states... DONE
Applying auth.0002_add_default_usergroup_osmaxx...Traceback (most recent call last):
File "manage.py", line 17, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 393, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 444, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/commands/migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 110, in migrate
self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 148, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/migration.py", line 115, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/operations/special.py", line 183, in database_forwards
self.code(from_state.apps, schema_editor)
File "/home/osmaxx/source/osmaxx/contrib/auth/migrations/0002_add_default_usergroup_osmaxx.py", line 16, in update_site_forward
permission = Permission.objects.get(codename='add_extractionorder', content_type=content_type)
File "/usr/local/lib/python3.4/dist-packages/django/db/models/manager.py", line 127, in manager_method
return getattr(self.get_queryset(), name)(*args, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/django/db/models/query.py", line 334, in get
self.model._meta.object_name
__fake__.DoesNotExist: Permission matching query does not exist.
What am I doing wrong?
The default permissions are created in a post_migrate signal handler, after the migrations have run. This won't be a problem if your updated code runs as part of the second manage.py migrate run, but it is a problem in the test suite and any new deployment.
The easy fix is to change this line:
permission = Permission.objects.get(codename='add_extractionorder',
content_type=content_type) # line 16
to this:
permission, created = Permission.objects.get_or_create(codename='add_extractionorder',
content_type=content_type)
The signal handler that creates the default permissions will never create a duplicate permission, so it is safe to create it if it doesn't exist already.
Im trying to migrate my django model:
from django.contrib.auth.models import User
class Post(models.Model):
headline = models.CharField(max_length=200)
slug = models.SlugField(max_length=200)
body = models.TextField(blank=True, null=True)
author = models.ForeignKey(User, null=True, blank=True)
I added the author field after I created the model.
Here is the migration django creates:
# encoding: utf8
from django.db import models, migrations
class Migration(migrations.Migration):
dependencies = [('articles', '0002_auto')]
operations = [
migrations.AddField(
field = models.ForeignKey(to_field=u'id', to=u'auth.User', blank=True, null=True),
name = 'author',
model_name = 'post',
),
]
Here is my traceback when I try to run ./manage.py migrate:
Operations to perform:
Synchronize unmigrated apps: ckeditor, sessions, admin, messages, auth, staticfiles, contenttypes, django_extensions
Apply all migrations: articles
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Installed 0 object(s) from 0 fixture(s)
Running migrations:
Applying articles.0002_post_author...Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/core/management/__init__.py", line 397, in execute_from_command_line
utility.execute()
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/core/management/__init__.py", line 390, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/core/management/base.py", line 289, in execute
output = self.handle(*args, **options)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/core/management/commands/migrate.py", line 116, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/migrations/executor.py", line 60, in migrate
self.apply_migration(migration, fake=fake)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/migrations/executor.py", line 73, in apply_migration
migration.apply(project_state, schema_editor)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/migrations/migration.py", line 80, in apply
operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/migrations/operations/fields.py", line 22, in database_forwards
schema_editor.add_field(from_model, to_model._meta.get_field_by_name(self.name)[0])
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/backends/schema.py", line 349, in add_field
definition, params = self.column_sql(model, field, include_default=True)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/backends/schema.py", line 105, in column_sql
db_params = field.db_parameters(connection=self.connection)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/models/fields/related.py", line 1285, in db_parameters
return {"type": self.db_type(connection), "check": []}
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/models/fields/related.py", line 1276, in db_type
rel_field = self.related_field
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/models/fields/related.py", line 1183, in related_field
return self.foreign_related_fields[0]
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/models/fields/related.py", line 971, in foreign_related_fields
return tuple(rhs_field for lhs_field, rhs_field in self.related_fields)
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/models/fields/related.py", line 958, in related_fields
self._related_fields = self.resolve_related_fields()
File "/home/USER/.virtualenvs/PROJECT/src/django-trunk/django/db/models/fields/related.py", line 943, in resolve_related_fields
raise ValueError('Related model %r cannot been resolved' % self.rel.to)
ValueError: Related model u'auth.User' cannot been resolved
Anyone know what I'm doing wrong?
What helped me in this situation:
Delete all migration files except __init__.py (/%prjname%/migrations folder)
python manage.py makemigrations
python manage.py migrate
Not sure about exact cause, but i tried to use files, generated by my code-partner and it didn't work out.
Ok, this is another funky feature of Django which cost me hours to figure it out. According to https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model:
Due to limitations of Django’s dynamic dependency feature for swappable models, you must ensure that the model referenced by AUTH_USER_MODEL is created in the first migration of its app (usually called 0001_initial); otherwise, you will have dependency issues.
So to solve this problem the best "clean" way is to put your custom user model creation in 0001_initial.py and it will simply work. And that's the real reason why Lebedev Sergey's delete/makemigrations trick can work.
If you make this change after you have applied ANY other migrations, you need to delete everything else in the migration folder and then run "python manage.py makemigrations". Then whatever you used for AUTH_USER_MODEL will be your first migration.
This probably isn't your problem if you're not using a custom user model, but remember to always use get_user_model() or when referencing the User class. Also, when defining a foreign key, settings.AUTH_USER_MODEL works, too, as in:
class MyModel(models.Model):
person = models.ForeignKey(settings.AUTH_USER_MODEL)