I am upgrading my app from Django1.7->Django1.8, but I can't make any changes or even run migrations because I keep seeing the following system error whenever I attempt to perform any migration operation in the 1.8 environment
ERRORS:
content.Content.polymorphic_ctype: (fields.E306) The name 'polymorphic_content.content_set' is invalid related_name for field Content.polymorphic_ctype
HINT: Related name must be a valid Python identifier or end with a '+'
content.Tag.polymorphic_ctype: (fields.E306) The name 'polymorphic_content.tag_set' is invalid related_name for field Tag.polymorphic_ctype
HINT: Related name must be a valid Python identifier or end with a '+'
promotion.PZoneOperation.polymorphic_ctype: (fields.E306) The name 'polymorphic_promotion.pzoneoperation_set' is invalid related_name for field PZoneOperation.polymorphic_ctype
HINT: Related name must be a valid Python identifier or end with a '+'
reviews.MediaItem.polymorphic_ctype: (fields.E306) The name 'polymorphic_reviews.mediaitem_set' is invalid related_name for field MediaItem.polymorphic_ctype
HINT: Related name must be a valid Python identifier or end with a '+'
The problem is that 3 of those apps are part of a dependency and have already updated the related_name of the 3 fields to end with + in the 0001_initial.py migration, but I can't revert backwards due to the system errors. Kind of at loss with how to proceed with updating.
Try deleting and re-generating your migrations with manage.py makemigrations <appname> for each app.
I had troubles with migrations after upgrading too. If wiping your whole DB and repopulating it from a scratch is an option, try this (after cleaning the DB):
1) run ./manage.py makemigrations app_name for each app
2) run ./manage.py migrate
3) run ./manage.py syncdb
Related
I am using 3 Date-Fields in models.py and after makemigrations, I did migrate and turned into an error.
Error:
d
> jango.core.exceptions.ValidationError: ["'Date' value has an invalid
> date format. It must be in YYYY-MM-DD format."]
Even I removed all the model fields on models.py file and then migrated, but still giving the error.
Please anyone who knows the best solution?
Here is a shot in the dark:
Try reverting your last migration with the following:
./manage.py migrate myapp xxxx_previous_migration
where xxxx is your previous migration. If you are unsure of what your previous migration was, you can run ./manage.py showmigrations myapp to see a list of all migrations made in myapp
(I am aware that a number of Django users have had the same issue.
I have looked at a number of solutions online but none has worked for me so far.)
I have set up my apps.py, settings.py and models.py files as explained in Django official tutorial (please see the 3 files below).
When I enter in the terminal:
$ python3 manage.py makemigrations munichliving_app
It returns:
No changes detected in app 'munichliving_app'
(file settings.py) in INSTALLED_APP --> I added and tested both one at a time:
'munichliving_app' and
'munichliving_app.apps.MunichLivingConfig'
apps.py file: https://pastebin.com/raw/qaYy1x44
setting.py file: https://pastebin.com/raw/cSsbfPsx
models.py: https://pastebin.com/raw/U0QeM16k
Django official tutorial states that I should see something along the lines of:
Migrations for 'polls':
polls/migrations/0001_initial.py:
- Create model Choice
- Create model Question
- Add field question to choice
Thank you.
Your app is munichliving (the module that contains models.py), but you have munichliving_app in your INSTALLED_APPS setting. The munichlivin_app is the project folder (the one that contains settings.py). It doesn't normally contain models so you shouldn't usually have to add it to INSTALLED_APPS or make migrations for it.
Replace 'munichliving_app' with 'munichliving' in your INSTALLED_APPS.
Next, I would remove your apps.py because it doesn't appear to be used. If you do keep it, then change it to name='munichliving', then use'munichliving.apps.MunichLivingConfig'inINSTALLED_APPS`.
Finally, create migrations with
./manage.py makemigrations munichliving
Try this:
python manage.py migrate --fake appname
Or delete the migration folder in your app, go to the database and delete the file in django_migrations table, then migrate again:
python manage.py makemigrations
python manage.py migrate
I try to add some array like in the example
tags = ArrayField(models.CharField(max_length=200),default=list)
I get this error:
django.db.utils.DataError: malformed array literal: ""
DETAIL: Array value must start with "{" or dimension information.
using postgresql_psycopg2...
I had the same error and I think the key is to delete the failed migrations as #nullable has pointed out.
I tried:
tags = ArrayField(models.CharField(max_length=50, blank=True), default=list)
And after deleting the failed migrations I was able to makemigrations and migrate. There seems to be no need to specify size, blank, or null.
Document Reference
Btw in your database there's a table called django_migrations where you can find the last successful migration.
topic_ids = ArrayField(models.IntegerField(blank=True), default=list)
After deleting the old migrations, re-execute
python3 manage.py makemigrations
python3 manage.py migrate
it worked for me
I changed one of my models to go from
serial_number = models.BigIntegerField(unique=True)
to
serial_number = models.AutoField(primary_key=True)
and ran
$ python manage.py check -v 3
$ python manage.py makemigrations -v 2
$ python manage.py migrate -v 2
However, when I try to run the unit tests (which passed fine before), I get this error:
[...]
File "/home/usr/Envs/intranet/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
raise errorclass, errorvalue django.db.utils.OperationalError: (1075, 'Incorrect table definition; there can be only one auto column and it must be defined as a key')
How to resolve this?
The Error1075 'Incorrect table definition' came from Mysql, not Django. That is because the table u changed got 2 auto_created fields, while it is only one field alled allow for one table in Mysql.
In Django, just add a parm 'auto_created'：
serial_number = models.AutoField(primary_key=True， auto_created=False)
then remove u old migrations file last time and make migrations again, continue migrate will be ok.
So far the only "solution" was to trash all the migrations and re-create the database. Thus trashing all the old data. But it is less of a pain than fixing this craziness.
I am trying to make an app using Django and am using South to handle migrations. After I define the app's models.py, I include south in the "INSTALLED_APPS" in settings.py. Then I sync my database. When I validate the database, I get 0 errors. Then I execute the following commands on the command prompt:
C:\Users\abagaria\Desktop\IntegrateID\website>python manage.py schemamigration w
ebsite.integrate --initial
Creating migrations directory at 'C:\Users\abagaria\Desktop\IntegrateID\website\
website\integrate\migrations'...
Creating __init__.py in 'C:\Users\abagaria\Desktop\IntegrateID\website\website\i
ntegrate\migrations'...
+ Added model integrate.Publisher
+ Added model integrate.Author
+ Added model integrate.Book
+ Added M2M table for authors on integrate.Book
Created 0001_initial.py. You can now apply this migration with: ./manage.py migr
ate integrate
C:\Users\abagaria\Desktop\IntegrateID\website>python manage.py migrate website.i
ntegrate
Running migrations for integrate:
- Migrating forwards to 0001_initial.
> integrate:0001_initial
FATAL ERROR - The following SQL query failed: CREATE TABLE "integrate_publisher"
("id" integer NOT NULL PRIMARY KEY, "name" varchar(30) NOT NULL, "address" varc
har(50) NOT NULL, "city" varchar(60) NOT NULL, "state_province" varchar(30) NOT
NULL, "country" varchar(50) NOT NULL, "website" varchar(200) NOT NULL)
The error was: table "integrate_publisher" already exists
! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
! schema-altering statements in transactions, we have had
! to leave it in an interim state between migrations.
! You *might* be able to recover with: = DROP TABLE "integrate_publisher"; []
= DROP TABLE "integrate_author"; []
= DROP TABLE "integrate_book"; []
= DROP TABLE "integrate_book_authors"; []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
! NOTE: The error which caused the migration to fail is further up.
Error in migration: integrate:0001_initial
DatabaseError: table "integrate_publisher" already exists
I know that a lot of people have faced similar problems while using south, but usually in their case, they make the mistake of executing the "--initial" command more than once-- thereby causing south to make more than one __initial file in the migrations directory. But in my case, South thinks that the table already exists even when I make the first migration!
I have also tried:
deleting the migrations directory
deleting ghost migrations
making a "fake" migration
and then running the actual migration
Can someone please tell me how I fix this problem and can start defining my models again?
If you already have tables in database, do not use --initial, instead you need convert_to_south command. Delete directory "migrations", all tables from database and run the following commands:
python manage.py syncdb
python manage.py convert_to_south appname
python manage.py syncdb --migrate
http://south.readthedocs.org/en/latest/convertinganapp.html