Since upgrading to django 1.8 I've been having some issues with datetime fields in my models not migrating correctly.
I was seeing this message repeatedly:
Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
I run makemigrations and I get this:
operations = [
migrations.AlterField(
model_name='profile',
name='date_of_hire',
field=models.DateField(default=datetime.date(2016, 6, 5)),
),
]
So I run manage.py migrate and then i get:
Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
So I run make migrations again and I get an new migration identical to the one above.
here's my problem field:
date_of_hire = models.DateField(default=datetime.date.today())
Looking at the migration I can see that the date is getting explicitly set to a fixed date. So now if I change my field to this:
date_of_hire = models.DateField(auto_now_add=True)
or this:
date_of_hire = models.DateTimeField(auto_now_add=True)
I get the error below when trying to run makemigrations or start my server:
File "/urls.py", line 13, in <module>
import profiles.views as profile_views
File "/profiles/views.py", line 9, in <module>
from profiles.forms import CompanyProfileForm
File "/profiles/forms.py", line 19, in <module>
class ProfileForm(ModelForm):
File "/usr/local/lib/python2.7/dist-packages/django/forms/models.py", line 295, in __new__
raise FieldError(message)
django.core.exceptions.FieldError: Unknown field(s) (date_of_hire) specified for Profile
If I comment out that field in the forms.py fields list everything except the for the form works. I can make migrations and apply them, run the server, etcetera, but as soon as I uncomment that field the app take a crap. So I am at a loss...
In your default, you should pass the callable datetime.date.today, instead of calling it:
date_of_hire = models.DateField(default=datetime.date.today)
When you use default=datetime.date.today(), Django calls today() every time you load your models.py. This changes the default, so Django thinks a new migration is required.
You'll have to create one more migration to change the default to datetime.date.today (or edit the existing migrations but that will be trickier).
Related
Am trying to load some generated data into Django without disrupting the existing data in the site. What I have:
Saved the data as a valid JSON (validated here).
The JSON format matches the Django documentation. In previous attempts I also aligned it to the Django documentation here (slightly different field order, the result was the same).
Output errors I'm receiving are very generic and not helpful, even with verbosity=3.
The Error Prompt
Operations to perform:
Apply all migrations: workoutprogrammes
Running migrations:
Applying workoutprogrammes.0005_auto_20220415_2021...Loading '/Users/Robert/Desktop/Projects/Powerlifts/src/workoutprogrammes/fixtures/datafile_2' fixtures...
Checking '/Users/Robert/Desktop/Projects/Powerlifts/src/workoutprogrammes/fixtures' for fixtures...
Installing json fixture 'datafile_2' from '/Users/Robert/Desktop/Projects/Powerlifts/src/workoutprogrammes/fixtures'.
Traceback (most recent call last):
File "/Users/Robert/Desktop/Projects/Powerlifts/venv/lib/python3.8/site-packages/django/core/serializers/json.py", line 70, in Deserializer
yield from PythonDeserializer(objects, **options)
File "/Users/Robert/Desktop/Projects/Powerlifts/venv/lib/python3.8/site-packages/django/core/serializers/python.py", line 93, in Deserializer
Model = _get_model(d["model"])
KeyError: 'model'
The above exception was the direct cause of the following exception:... text continues on...
for obj in objects:
File "/Users/Robert/Desktop/Projects/Powerlifts/venv/lib/python3.8/site-packages/django/core/serializers/json.py", line 74, in Deserializer
raise DeserializationError() from exc
django.core.serializers.base.DeserializationError: Problem installing fixture '/Users/Robert/Desktop/Projects/Powerlifts/src/workoutprogrammes/fixtures/datafile_2.json':
auto_2022_migration.py file:
from django.db import migrations
from django.core.management import call_command
def db_migration(apps, schema_editor):
call_command('loaddata', '/filename.json', verbosity=3)
class Migration(migrations.Migration):
dependencies = [('workoutprogrammes', '0004_extable_delete_ex_table'),]
operations = [migrations.RunPython(db_migration),]
JSON file extract (start... end)
NB: all my PKs are UUIDs generated from postgresql
[{"pk":"af82d5f4-2814-4d52-b2b1-6add6cf18d3c","model":"workoutprogrammes.ex_table","fields":{"exercise_name":"Cable Alternating Front Raise","utility":"Auxiliary","mechanics":"Isolated","force":"Push","levator_scapulae":"Stabilisers",..."obliques":"Stabilisers","psoas_major":""}}]
I'm not sure what the original error was. I suspect it had to do with either editing the table/schema using psql separately from Django, OR using the somewhat outdated uuid-ossp package instead of pgcrypto package (native to Djagno via CryptoExtension()). I was never able to confirm. I did however manage to get it working by:
Deleting the table (schema, data) using psql and the app using Django. Creating a new app in Django.
Load the prev model data into this new_app/models.py. Make new migration file, first updating the CryptoExtension() operation before committing the migration.
Create Fixtures directory and relevant file (per Django specs, validated JSON online.
Validate my UUIDs online
Load the fixture data into the app. python3 manage.py loaddata /path/to/data/file_name.json
I initially created a database in mysql and used inspectdb to create all the models. So far so good, but then I started trying to make changes to the models and migrating them. I added columns to no avail, there were no changes in the database even though the migrations folder showed the changes. I began to wonder if it was something to do with case, so I tried again with a second model TestTwoT with table name and all fields in lower case. I then ran the make migrations which produced this output:
Migrations for 'testdb':
testdb/migrations/0010_testtwot.py
- Create model TestTwoT
The generated .py file in the migrations folder (which looks fine to me):
# Generated by Django 3.0.1 on 2020-02-10 22:46
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('testdb', '0009_auto_20200210_2241'),
]
operations = [
migrations.CreateModel(
name='TestTwoT',
fields=[
('id', models.AutoField(db_column='id', primary_key=True, serialize=False)),
('name', models.CharField(blank=True, db_column='name', max_length=1000, null=True)),
],
options={
'db_table': 'test_two_t',
'managed': True,
},
),
]
I then ran the migrate script which produced this output suggesting there were no problems creating the table:
Operations to perform:
Apply all migrations: admin, auth, contenttypes, testdb, sessions
Running migrations:
Applying testdb.0010_testtwot... OK
However, still no sign of my new table when I run the 'show tables' sql command or the 'describe test_two_t' command.
There is another complication in my scenario in that I am not using the default database, but my setup seems entirely OK and my application is working fine pointing to the database.
EDIT : Following Borut's advice I changed the commands to (adding the --database parameter):
python3 manage.py makemigrations
python3 manage.py migrate --database=testdb
EDIT2 : It's all working perfectly now (after I also deleted all the previous migration .py files and started from scratch with the corrected above commands).
Following Borut's advice I changed the commands to (adding the --database parameter):
python3 manage.py makemigrations
python3 manage.py migrate --database=testdb
It's all working perfectly now (after I also deleted all the previous migration .py files and started from scratch with the corrected above commands).
I tried Googling this problem, but I mostly saw answers that were from versions of Django where South was needed for migration and/or syncdb was still a thing. The ones that were relevant matched the symptom, but not the cause.
I started with the default project/app that Django creates when you do django-admin startproject project-name and django-admin startapp products.
models.py
from django.db import models
from django.contrib.auth.models import User
from django.core.exceptions import ObjectDoesNotExist
# Create your models here.
class Artist(models.Model):
user = models.OneToOneField(User, null=True, blank=True)
name = models.CharField(max_length=50)
def __str__(self): return "<Artist: %s>"%self.name
class Category(models.Model):
artists = models.ManyToManyField(Artist)
name = models.CharField(max_length=50)
desc = models.CharField(max_length=200)
My process:
python manage.py flush to clear the database
rm -rf products\migrations to delete prior migrations
python manage.py migrate
Output:
Operations to perform:
Apply all migrations: sessions, contenttypes, auth, admin
Running migrations:
No migrations to apply.
python manage.py makemigrations products
Output:
Migrations for 'products':
0001_initial.py:
- Create model Artist
- Create model Category
python manage.py migrate
Output:
Operations to perform:
Apply all migrations: contenttypes, admin, sessions, products, auth
Running migrations:
No migrations to apply.
At this point, I'm confused. Aren't there migrations to be applied, and yet there aren't any? I press on nonetheless.
python manage.py shell
In this shell, I enter these commands:
>>> from products.models import *
>>> artist = Artist(name="foo")
>>> artist.save()
>>> categ = Category(name="bar", desc="baz")
>>> categ.save()
>>> categ.artists.add(artist)
At this point, I get a huge error traceback. The problem seems to be this:
django.db.utils.OperationalError: no such table: products_category_artists
I see the same error if I try to use the built-in admin site.
My guess is that the problem is that migrations aren't actually being applied or that a particular table isn't being created, but I don't know how to fix either of these problems.
There is a table generated by django called django_migrations which keeps track of what migrations have been applied. If you delete your migrations, re-generate them and try to migrate without deleting the records from the table than django will think it already applied them. You should never delete your migrations, it will cause django to get confused.
If you are actively developing and want to skip the entire migrations system you can, but once you start using migrations, never delete them. Here is what I use while developing a new project:
dropdb mydb && createdb mydb && python manage.py migrate --run-syncdb && python manage.py loaddata initial
First, it drops the database and all data. Then it creates an empty one. The --run-syncdb generates the schema and the loaddata loads data from a fixtures file.
So, if you are still developing and can delete all your data and move what you care about to a fixtures file than you can delete all your migration folders and run the command above each time you change your model.
I have two applications (ook and eek say) and I want to use a foreign key to a model in ook from a model in eek. Both are in INSTALLED_APPS with ook first.
In ook.models.py, i have:
class Fubar(models.Model):
...
In eek.models.py, I have:
class monkey(models.Model):
external = models.ForeignKey('ook.Fubar', blank=True, null=True)
...
The migration generated is:
class Migration(migrations.Migration):
dependencies = [
('eek', '0002_auto_20151029_1040'),
]
operations = [
migrations.AlterField(
model_name='monkey',
name='external',
field=models.ForeignKey(blank=True, to='ook.Fubar', null=True),
),
]
When I run the migration, I get this error:
...
1595 raise ValueError('Foreign Object from and to fields must be
the same non-zero length')
1596 if isinstance(self.rel.to, six.string_types):
-> 1597 raise ValueError('Related model %r cannot be resolved' % self.rel.to)
1598 related_fields = []
1599 for index in range(len(self.from_fields)):
ValueError: Related model u'ook.Fubar' cannot be resolved
What am I doing wrong?
Because You have ForeignKey in operations, You must add a ook to dependencies:
dependencies = [
('ook', '__first__'),
('eek', '0002_auto_20151029_1040'),
]
Django migrations have two "magic" values:
__first__ - get module first migration
__latest__ - get module latest migration
Try running migrations one by one for every model.
This way you can debug the app you are facing problem with
python manage.py migrate appmname
I just got the same error, but referring to a model that was declared as part of the same migration. It turned out that the first migrations.CreateModel(...) referred to a not yet declared model. I manually moved this below the declaration of the referred model and then everything worked fine.
In my case, It was the cache and previous migrations that resulted in this error. I removed __pycache__ and migrations folder and then re-run the migrations command and it worked.
Remember, when you'll do python manage.py makemigrations it won't see any new migrations and will console output no changes detected. You'll have to do python manage.py makemigrations your_app_name instead to make things work.
I encountered this error when trying to use a child model of a base model as a foreign key. It makes sense that it didn't work because there's not an id field on the child model. My fix was to use the parent on the key. Unfortunately this was not immediately intuitive and set me back a couple hours.
I have found that it looks like this bug was not fixed yet when you scroll down to the bottom.
Django ValueError: Related model cannot be resolved Bug
I am using 1.11.7, they are talking about 1.9.3.
It worked everything on localhost, but was always failing on Heroku, so I tested all the options/answers above and nothing worked.
Then I have noticed, localhost DB in Admin I had 1 profile created (1 DB record), went to Heroku and DB has 0 records for Profile table so I have added 1, pushed the migration, python manage.py migrate and all it went OK.
That validates that I did not need to change any of those migrations manually that all is working.
Maybe it will help to someone.
migrations
# -*- coding: utf-8 -*-
# Generated by Django 1.11.7 on 2017-11-23 21:26
from __future__ import unicode_literals
from django.db import migrations, models
import django.db.models.deletion
class Migration(migrations.Migration):
dependencies = [
('blog', '0005_blog_author'),
]
operations = [
migrations.AlterField(
model_name='blog',
name='author',
field=models.ForeignKey(on_delete=django.db.models.deletion.CASCADE,
to='core.Profile'),
),
]
order of dependencies is too important.
in your case, ook must be created first then depend eek on it.
dependencies= [
('ook', '0001_initial'),
('eek', '0002_auto_20151029_1040'),
]
I am working with Postgres on a Django app and I want to make a model change, resetting a row so it is no longer the primary key.
This is what my model currently looks like in Django:
class Meeting(TimeStampedModel):
row = models.CharField(max_length=20, primary_key=True)
total_items = models.IntegerField()
I have run django-admin.py flush to remove all data from the database. If I run python manage.py makemigrations I see No changes detected. So we are starting from a clean base.
Now I edit row in models.py so it is no longer the primary key:
row = models.CharField(max_length=20)
And run python manage.py makemigrations and set 1 as the default when asked:
You are trying to add a non-nullable field 'id' to meeting without a default; we can't do that (the database needs something to populate existing rows).
Please select a fix:
1) Provide a one-off default now (will be set on all existing rows)
2) Quit, and let me add a default in models.py
Select an option: 1
Please enter the default value now, as valid Python
The datetime and django.utils.timezone modules are available, so you can do e.g. timezone.now()
>>> 1
Migrations for 'frontend':
0007_auto_20150305_1129.py:
- Add field id to meeting
- Alter field row on meeting
That seems to run OK. Then if I run python manage.py migrate:
$ python manage.py migrate
Operations to perform:
Synchronize unmigrated apps: debug_toolbar
Apply all migrations: contenttypes, frontend, sites, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
Applying frontend.0007_auto_20150305_1129...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Users/me/.virtualenvs/meetings/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
...
File "/Users/me/.virtualenvs/meetings/lib/python2.7/site-packages/django/db/backends/utils.py", line 65, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: multiple default values specified for column "id" of table "frontend_meeting"
Why is it telling me I have multiple default values?
Do I need to set a unique primary key value as a default - and if so, how can I do this?
This is what the migrations file looks like:
class Migration(migrations.Migration):
dependencies = [
('frontend', '0006_auto_20150305_1050'),
]
operations = [
migrations.AddField(
model_name='meeting',
name='id',
field=models.AutoField(auto_created=True, primary_key=True, default=1, serialize=False, verbose_name='ID'),
preserve_default=False,
),
migrations.AlterField(
model_name='meeting',
name='row',
field=models.CharField(max_length=20),
preserve_default=True,
),
]
Try to use an intermediate migration to achieve this:
1) Add id = models.IntegerField() to your model.
Run makemigrations and then migrate.
2) Remove primary_key=True from the 'row'-field, and also remove the 'id'-field. Again run makemigrations and migrate.