I have deleted a class from model.py but whenever I run python manage.py migrate, I get this:
intergrityerror : not null constraint failed: appname_modelclassfieldname.user_id
The most challenging thing is that I had already deleted the model class of the related field django is pointing error at.
You have to create a migration before running migrate. As you have not specified your Django version, here is what you need to do for the most recent version (1.11) which also works down to at least 1.9:
$ ./manage.py makemigrations # > creates a migration file
$ ./manage.py migrate
You can specify the the app in the makemigrations call if you want.
Concerning:
The most challenging thing is that i had already deleted the model class of the related field django is pointing error at .
Use a version system for your own health (e.g. GIT) or an editor that supports local versioning (like PyCharm) - best use both - even if you are working alone. (You are never alone, after some weeks, the code looks like it was written by someone else...)
The problem was an error with the server .I had delete the app and create a new one ,and everything is working just fine now
Related
I changed the name of the attributes of one of my models. As soon as I made the change in the models.py script, I tried to migrate it using makemigrations command, but it kept giving me an error that the email field is non-nullable and the database needs something to populate the existing rows. So I tried to reverse the previous migrations and ran the command python3 manage.py <app_name> zero.
After this the previous non-nullable field error was resolved at the command line but as soon as I submit the form at the browser, I run into this Operational error.
The crux of the matter is how to make changes to the attributes of one of the models in models.py and deal with the consequent migrations ?
You might want to delete your database or running the python manage.py flush commands when making such changes. If you do not want to do that, just add a one-time default (make sure its the right type).
I have created a model and executed syncdb which had created the tables as my model was designed.
Afterwards I modified the model and executed makemigrations which created the migrations ignoring the tables that syncdb had already created.
So I ended up with an error "relation already exists".
Why did makemigrations created everything from scratch?
How do I fix this situation ?
makemigrations creates new migrations based on the changes detected to your models.
Also, one thing to note is syncdb command is deprecated since Django 1.7 and will be removed in Django 1.9. So, you should use the migrate command.
From syncdb docs:
Deprecated since version 1.7:
This command has been deprecated in
favor of the migrate command, which performs both the old behavior as
well as executing migrations.
makemigration always creates one migration file having all the changes. So, when you run makemigration for first time it tries to find the previous migration file. if not found it creates one initial migration file. And when it tries to apply it to the db it finds the relation already exists. And thus throws error.
Best practice is, before updating model, create one migration then modify the model.
One of our clients needs to add some geolocation data to their
site. Since they already have a database setup without GIS extensions,
I decided to create a new database (with the GIS extensions), which I
intend to use to store only the geolocation data.
I had, at some point, set things up to work alright on my development
machine (meaning, I have migrations for these new models). But now that the code has been written, I imported a DB dump
directly from the server so that my development machine exactly
mirrors the production machine, and now I can't seem to get South to
apply the migrations correctly. South seems to have several features
which allow for multiple databases, but none of them have worked so far.
What I've tried:
Just adding the model and migrating. This gives me the following
error:
AttributeError: 'DatabaseOperations' object has no attribute
'geo_db_type'
OK, so South is trying to create the model on the original database
which doesn't have the GIS extensions.
Adding the model, but specifying the 'geo' database for migrating
the 'geo' app. This gives me the following error:
django.db.utils.DatabaseError: relation "south_migrationhistory"
does not exist
I guess south expects its MigrationHistory table to exist on the 'geo'
database as well?
Allow south's models to exist on my 'geo' database.
$ python manage.py syncdb --database=geo
$ python manage.py migrate
This gives me the following error:
django.db.utils.DatabaseError: relation "<model>" already exists
I'm guessing this is because I already have MigrationHistories stored
in the other database?
South apparently has a sparsely documented feature called 'dbs'
(see:
http://south.aeracode.org/docs/databaseapi.html#accessing-the-api )
So I tried the previous three methods again replacing all instances of
"db" with "dbs['geo']".
a. Migrations run smoothly, but don't actually create any tables
in my 'geo' database.
b. Same error as when not using 'dbs' features.
c. Same error as when not using 'dbs' features.
This entire process has been extremely frustrating. Has anyone got
multiple database support up-and-running when using South?
Whenever I have modified the table models I used south and these commands to modify the structure and they always worked:
python manage.py convert_to_south "your_app"
python manage.py migrate "your_app"
I recommend running these commands after running syncdb, so your tables are created.
I'm using South (version 0.6, the one packaged in Ubuntu Lucid Lynx) to manage database migrations in Django, and currently using SQLite as a back end. I came across a situation where I generated a migration to add a column with:
./manage.py startmigration myapp --auto added_new_column
... which generated a migration that looked sensible. However, when I then applied the migration with:
./manage.py migrate myapp
I got an error because the column I was adding was non-NULL, but I hadn't specified a default value:
ValueError: You cannot add a null=False column without a default value.
What is one supposed to do if a migration fails in this way, and you want to go back and regenerate it? (What I did in practice, namely to delete the migration and generate a new one, has created several further problems.) Perhaps I've missed something obvious in the documentation about this...
In this case, migration failed and didn't get written into db, so you can safely remove old one and create again. Also you can try using newer south version, i believe they added default check for NOT NULL fields on creating step.
This problem is basically the same as the previous question
here.
However, the answer there does not work for me. I've installed the trunk version of south, manually entered the import line in the migration file in question, and done a full 'startmigration' in a separate directory and examined the 0001_initial.py file.
I have a Django project with several applications in it, one of them (named 'core') being referred to by the others. The south migration is trying to create a new table, with a column that has a foreign key to a model in core.
I'm currently importing core in the migration in question (0006), and I even added it to migration 0001, although it doesn't seem like that should matter.
Before I do something drastic, like removing that field, running the migration, and adding the field manually, is there a known manual workaround for fixing this south issue?
You probably did not use the --freeze option like this:
python manage.py startmigration <appname> migrate_core --freeze core
Having created a migration like so:
./manage.py startmygration appname --model NewModel
This error occurs:
"The model 'program' from the app 'core' is not available in this migration."
Recreating the migration like this fixes it:
./managepy startmigration appname --model NewModel --freeze core.Program
Just doing "--freeze core" did not do the trick for me.
You can receive this error by trying to access a class that resides in another django app. Check to make sure the class you are trying to access is in the models dictionary.