I had to change a field in my model from date to integer. Schemamigration could not do this so i had to delete the table (there was no data so it didn't matter). After i made the change I tried to create a new schemamigration to create the new table with the updated field. For some reason schemamigration could not find any changes. I tried to run migrate anyway and it said relation "tablename" does not exist. I tried dbsync but it skips my project. It says i have to use migration.
Any ideas of what to do / what could be causing this issue?
-Thanks
You probably still have the old migrations in the south/ folder. If you anyway start with a new database, you can as well delete the old migrations.
Create the table as before your change.
Delete the model
Run schemamigration to create the 'delete table' migration
Create correct model
Run schemamigration to create the 'create table' migration
Apply migrations
Related
I have two this model, which I want to move to another app.
After running this migration, I successfully could see the model under the required app.
But when I added another field, It was adding the entire model to the new migrations in new_app.
According to most tutorials, it should have added just the field.
I don't wanna fake the migrations, as it can cause issues.
Please point out my mistake.
Problem: On adding a new field in new_app model, the migrations has "CreateModel". How to avoid this?
Please help.
Migrations are persisted on your db, there's a dedicated table that keeps the track of your changes. You shouldn't modify migrations directly.
My suggest:
for development purpose you can delete your migration's files and migration's table.
Try to create your migration once you moved your model If you can't delete anything,
then you should have something like.
users/0001_mymodel.py
users/0002_mymodel_deleted.py
otherapp/0001_mymodel_added.py
otherapp/0002_adding_field.py
django.db.utils.IntegrityError: column "required_tem_grid" contains null values
So I mistakenly gave wrong type of value when Django asked me to provide default value for existing rows. Problem is now that I am stuck with this error. I have been burned by this error before too and the only way I could recover was to create another db and running migrations again. Is there any other way? I have tried to revert to previous migration (initial) but this error pops up everywhere. There is no such column in the database that I can see. Is there some place this default value gets cached?
Well I managed to solve it this way: Delete migration files and cached files, remove offending entry from models, delete migration data from django_migrations table for the app, run makemigrations and migrate --fake-initial. I was then able to change models and run migrations.
Situation: a project I'm working in had a file corruption or something. Models are the latest version, but the SQLite DB had to be rolled back before some columns were added/removed/modified. Migration files are all gone. Trying to create migrations anew results in the new columns being present in the initial migration file, so I can neither migrate for real (due to the table existing) nor fake it (since the columns are missing in the DB).
Given those circumstances, how can I make an initial migration matching the columns currently present in the DB so I can fake it and then make a real second migration to bring the tables in line with the models? The only thing that comes to mind is manually tweaking the models to match the DB schema, making the initial migration, faking it and then restoring the new version of the models, but I'd much prefer having this done automatically.
django inpsectdb to the rescue.
But first, learn how to use git if you had used proper version control, you would not be facing this difficulty now.
First step, add the code to version control.
Delete the existing models files
Use inspectdb to generate a models.py from the tables in the database. This is not perfect, you will have to edit the file manually and you may have to spread it out between different models files manually.
Now delete the contents of the migrations table
do a ./manage.py makemigrations (yourapp)
Do the fake migration you mentioned
replace the generated models.py with your current models.py (a git checkout of that file will do the trick nicely)
do a makemigrations and migrate again.
good luck.
I have created a model and migrated in Django, with a unique key constraint for one of the field. Now am trying to remove the unique constraint and generate another migration file with the new change, but it says "Nothing seems to have changed".
I tried with the command
python manage.py schemamigration --auto
PS: I am using OnetoOne relationship for the field.
Good question. A one to one relationship implies that one record is associated with another record uniquely. Even though the unique constraint is removed(for one to one field) in the code explicitly, it won't be reflected in your DB. So it won't create any migration file.
If you try the same thing for foreign constraint, it will work.
I find the django automigration file generation problematic and incomplete.
Actually I experienced another similar problem with django migration just yesterday.
How I solved it:
delete all migration files from the /migrations folder
do a fresh makemigrations
run python manage.py migrate --fake so django does not try to rebuild..
Hey presto! Working and models updated :D
I have 4 models. I want to redo 1 one of them that I've been working on. The other 3 models have user data that I don't want to lose.
I want to entirely drop one table, and sync it up with what's in models.py.
How do I do this?
You could remove the model from models.py, and create a migration which will drop the table.
./manage.py makemigrations
Then add the model back to your models.py, and create a new migration which will recreate the model.
./manage.py makemigrations
Finally, run your migrations and you should be done.
./manage.py migrate
It's not very clear what you want to do here.
You can write new model class and delete old model class that you want to remove. After that run migrations the normal way.
It will delete the table related to deleted model class and make whatever othe changes you have defined in the models.