If I make a change to a model in django it no longer picks up changes with
python manage.py makemigrations
I did previously delete the database (postgres) via dropdb, and recreated it with createdb. I then deleted the migrations from the apps migrations folder. Before doing this makemigrations did work ok for that app.
What is the best way to fix?
Recreate the migrations folder with an __init__.py file. A shortcut for this is to run python manage.py makemigrations <app_label>. The app label here is important, otherwise it will treat your app as an unmigrated app and it won't create any migrations.
Try this:
python manage.py makemigrations app_name
Or, just add __init__.py file on each migrations folder.
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
Django 1.9.7, db.sqlite3 as DB
I have a Django project with several apps. For app "A", I had migrations, but I deleted them by accident and pushed to the remote git. Also, a lot of new stuff for other apps was pushed to the git during the day. Other apps don't depend on the "A" app models.
Everything worked until I decided to add a new field to the model of the "A" app. I got OperationalError: no such column: error. I tried to make initial migrations for the app "A" python manage.py migrate --fake-initial. I got new migrations but I still have the OperationalError: no such column:.
How to fix "A" app migrations without affecting other apps migrations?
From git point of view, you can do revert to previous commit.
git revert sha #commit sha of the last commit
OR
git reset --hard HEAD~n #n how many commits to remove.
git push --force
Fixing through django(possible if you didn't add any migrations later.),
python manage.py makemigrations APP_A --empty
python manage.py makemigrations APP_A
python manage.py migrate --fake
Unfortunately git revert didn't help me. In the end, I solved the problem by executing the following steps:
1.Manually delete all tables related to the "A" app in db.sqlite3.
2.Create new migrations and db.sqlite3 tables from existing schema:
python manage.py makemigrations A --empty
python manage.py makemigrations A
python manage.py migrate
3.Dump the tables data back into db.sqlite3 from a backup:
sqlite3 ~/Backup/A/db.sqlite3 ".dump table_name" | grep -v "CREATE" | sqlite3 db.sqlite3
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 have a production web project running with a decent amount of data in the MySQL db. I am trying to update the database with some changes to an app called "enterlink." I've made new elements in the existing models and created new models altogether. Before this migration, I have never touched the schema of the db since originally running syncdb to create it. When I run: "python manage.py makemigrations enterlink" the below output appears(pic). My question is, why is this happening? The DB already includes all the models that it lists in the picture so why is it registering those lists of models? When I go to finish the migration by doing "python manage.py migrate" or "python manage.py migrate --fake enterlink" (pic again), I get an output shown but my database schema remains identical to the old db and any new code generates errors. Can anyone tell me what is likely the problem? I would be really appreciative of any advice. It's been very frustrating since I'm not sure what I'm missing.
What you have done is that you have ran the command python manage.py syncdb before running python manage.py makemigrations myapp and python manage.py migrate myapp. That is why syncdb created the database schema and the migration was faked because schema already exists. I will suggest to use python manage.py makemigrations myapp and python manage.py migrate myapp and not to use syncdb as its deprecated in Django 1.7.
If you change anything in your model, just run makemigrations and migrate command. Syncdb isn't necessary.
This question and relevant answers are intriguing me. Thus I want to share my experience on maintaining live database and migrations.
Tested in django1.5.5
Initializing the database:
./manage.py syncdb --noinput
./manage.py migrate
./manage.py syncdb
Now I have created the database.
Doing a migration for an app:
./manage.py schemamigration myapp --initial
./manage.py migrate myapp --fake
Now do necessary changes in your model
./manage.py schemamigration myapp --auto
./manage.py migrate myapp
Im newbie for schemamigration too, but i will explain how it works for me:
First you create app and then
./manage.py sycndb, so tables are created then you can
./manage.py makemigrations myapp --initial
so now initial migrations are created and you should apply them
./manage.py migrate myapp
now you can change your models : add,change fields, anything you want and then
./manage.py makemigrations myapp --auto
this will create migrations for changes and now you need to apply them
enter code here./manage.py migrate myapp
so this actually will create new tables in db