I tried to squash migrations.
Unfortunately there are just too many circular dependencies.
Is there a way to start over the migrations (although my project is already deployed in production) than trying to squash the migrations?
I don't have to worry about some unknown developer using my project because it's a private project.
Yes, there is a way. See this similar question. In a nusthell:
# 1) Fake migrations back to 0
./manage.py migrate app zero --fake
# 2) Delete migrations files
git rm "app/migrations/*"
# 3) Create new migration file
./manage.py makemigrations app
# 4) Pretend to run the new migration
./manage.py migrate app --fake
Related
i am new to django developement after making changes to my model i tried to run the command python manage.py makemigrations my_app
it detects changes in my model and shows me the message
todoapp/migrations/0001_initial.py
- Create model confess
- Create model UserChoice
- Create model comment
but on executing python manage.py migrate my_appcommand i've got this message
No migrations to apply.
i usually do this after making changes in models, i don't know what happened now.
plss help me.
Firstly, try
python manage.py makemigrations my_app
python manage.py migrate
If this does not work and the project is still in development:
Delete migrations folder and pycache folder.
Delete db.sqlite3 (your database).
Make and apply migrations again.
I think this will work.
Delete all migrations files and __pychache__except__init__.py from your project and app. Also db.sqlite3 database then rerun makemigrations and migrate commands. It should solve your issue.
Suppose, we have a db's backup and a django program. The program do not have any migrations. First we restore db, that has created table and data. Now we want to make migrations from available db. Is it possible or not?
Yes, Django has the inspectdb method, which is described here.
But if the Django app already has the models defined that correspond to the backed up database, then you can just run makemigrations (follow #Shafikur's instructions).
Just go to your corresponding database terminals and delete all the records from you django_migrations table with
delete from django_migrations;
Go to terminal and run remove all files in migrations folder with
rm -rf <app>/migrations/
Reset all the migrations of the Django's built-in apps like admin with the command
python manage.py migrate --fake
Create initial migrations for each and every app:
python manage.py makemigrations <app>
To create initial fake migrations just run
python manage.py migrate --fake-initial
I'm using Django 1.8.4. As my project is still under construction, I frequently remove all migration scripts, and rerun makemigrations to generate the initial migration scripts.
I found makemigrations would generate two migration scripts for one of my apps while other apps just have 0001_initial.py. It would be something like:
- 0001_initial.py
- 0002_auto_20150919_1645.py
I checked the content of 0002_auto_20150919_1645.py, it was adding foreign field from the other app's model.
I guess it might be related to the order of creating migrations for apps. So I delete these two migration scripts of this app and then run makemigrations again. Now I have only one migration script for this app.
My questions is:
Is there any way I can control the order makemigrations create migrations for apps?
For example, I have two apps, app1 and app2, and app1 depends on app2. Is it possible makemigrations create migration for app2 first, and then app1?
You can manually run migrations for an individual app.
./manage.py makemigrations app2
./manage.py makemigrations app1
./manage.py makemigrations # migrate the rest of your apps
You could also squash your existing migrations.
I accidentally deleted the South migrations directory for one of my Django apps. This directory was not under git.
So now there are migrations in the database that are not present on the disk.
Some pointers on how I can recover from this will be much appreciated.
Without the option of any type of backup or finding the files somewhere, what you're going to have to do is make initial migrations and then fake them.
$ ./manage.py schemamigration app --initial
$ ./manage.py migrate app --fake
This will get you to where you are currently, however you won't have the option to migrate backwards.
I'm deploying a project on a new development environment.
As I'm using South I did:
$ python manage.py syncdb --all
$ python manage.py migrate --fake
I used syncdb --all to apply actual state of models.
Then migrate --fake to mark all models as migrated.
But after that, my model is not on the last version (missing fields)
What am I doing wrong ?
I assume all my modifications have migrations.
If I do
$ python manage.py syncdb
It seems to create the first state since when I used South (that is expected)
But then
$ python manage.py migrate
Some tables appears as already created
Actually this, should have been fine for my case
$ python manage.py syncdb --all
$ python manage.py migrate --fake
Having to redeploy my app recently, I faced the same issue.
I just realized that I had a double initial migration on the model that were causing the problem
0001_initial.py
0002_initial.py
0003_auto__add_field_mytable_myfield.py
I simply deleted & renamed
0001_initial.py
0002_auto__add_field_mytable_myfield.py
Then redone the whole database deployment (obviously not forgetting to update the already applied migrations on my other hosts)
--fake option does not avoid errors while trying to create new migrations. It records that migrations have applied without actually applying them.
Also, you need --ignore-ghost-migrations or --delete-ghost-migrations to achieve what you are looking for.
To convert an existing project to south, you first need to convert the app
Now, if you have already run --fake, to recover, you can do this:
Go to ./manage.py dbshell
DELETE FROM south_migrationhistory WHERE id > 0; //Note that this would delete everything in the table.
If you want to remove migrations of a specific app,
DELETE FROM south_migrationhistory WHERE app_name = 'blah'