I would just like to understand something about Django migrations. I have a project with several apps and most of them have their own database. Now, let's say I add one field to the app App_A in the models.py and run makemigrations App_A. Then this runs smoothly and tells me that there is just one field to be added. But when I run migrate --database=the_db_of_app_a it lists lots of migrations of other apps, but there I haven't change anything lately. So, I would like to know, why it does not only list the migrations of App_A.
Best regards
Related
So I started working on a project that is right now on production but the preovious dev kinda made a mess with migrations (or maybe I am wrong), the migrations in developement and in production are not the same (he gitignored them) and I can not start working because there are missing migrations in development so the database is no fully migrated.
Im thinking I can just delete all migrations in development, reset them but I don't think that is a good idea in production. What should I do?
Migrations have two purposes: 1. Creating schema of database, 2. Migrating existing data of database (For example when you change a field from IntegerField to CharField, you need to write some migrations to convert integers saved in database to their equal char.) This one is only needed for production. If you are missing these migrations, it is not a problem, Because you only need schema of database to develop. But how can you make sure you have the correct schema? Run python manage.py makemigrations and then python manage.py migrate. You are good to go and there is no need to delete any prior migrations.
When I run my Django project. It prints the following:
You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
I'm using raw queries and not using admin and models feature. So migrations will not be of any use for me.
How can I make Django to not ask for applying migration?
The settings file generated by django-admin startproject has several apps listed in INSTALLED_APPS. Go through that list and remove all apps you are not using.
Django migration maintains database and model schema same. It is preferable to use django migration to make both schema same, but there are some cases where you don't want to migrate database using your Django application like If you are using third party database, multiple application is using same database or your application purpose is read only. For such cases you can use fake migration to ignore propagating changes in database.
python manage.py migrate --fake
I just followed this procedure:
makemigrations (success)
migrate (success)
Copy the app on another server (with the migration files)
Create a new empty database on that server
migrate (success, it creates the correct schema)
Fill the new database with data
Just to test: migrate ....
At this point Django says I have "changes that are not yet reflected in a migration, and so won't be applied. Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them"
But when I run makemigrations, it creates a new one that wants to "Remove field" every foreign key and "Delete model" all of my models. If I run it it empties my database. My models.py are intact.
What is happening ??
I had the same problem in my project. Running forward I can say that django removes models that has no import (making the Delete model migration). The documentation says that you should import your model in the myApp/models/__init__.py file (see https://docs.djangoproject.com/en/1.11/topics/db/models/#organizing-models-in-a-package).
In my case I imported the model somewhere to make manipulations but model had been removing elsewhere.
I had made a useless import in an admin.py file that has solved my situation (I didn't try to follow the documentation and import it in the __init__.py but sure it should help).
I had not realized yet why does it work that way (hope that someone could note this moment) and also hope this solution will help you.
I've just had the same errors, but I hit the makemigrations building a migration full of Remove Field and Delete Model commands before I tried the migrate command.
In my case, the solution was related this being an old project I was resurrecting, and it had a number of Model.Meta.app_name values set, as well as entries in apps.py for each project. These were now in conflict with the way settings was interpreting the project, and even though my models were imported into views and admin, they weren't being seen by the migration code. Deleting these app_name tags on the models, and modifying the AppConfig name in apps.py solved this, so that the running makemigrations again caused the expected changes (alter field, etc), and all was fine.
I didn't find any other questions or answers that quite matched this one and my experience, so I hope if anyone else looks for this, they'll find it here like I did ;-)
I have a few projects with lots of South migrations, including ones that contain a fair amount of custom SQL that need to be run in a specific order. After upgrading to Django 1.7, this is the recommendation on how to convert a project to use South (from the Django documentation):
If you already have pre-existing migrations created with South, then the upgrade process to use django.db.migrations is quite simple:
Ensure all installs are fully up-to-date with their migrations.
Remove 'south' from INSTALLED_APPS.
Delete all your (numbered) migration files, but not the directory or __init__.py - make sure you remove the .pyc files too.
Run python manage.py makemigrations. Django should see the empty migration directories and make new initial migrations in the new format.
Run python manage.py migrate. Django will see that the tables for the initial migrations already exist and mark them as applied without running them.
In short, "wipe your existing migrations and Django will take care of the rest".
What is not mentioned here is what to do when existing South migrations don't only consist of model changes, but instead contain direct SQL, data migrations, etc, that need to be run in order. In this case, the auto-generated Django migrations will miss a lot of things, since not all of these changes are obvious from introspecting a models file.
Ideally, one would be able to run the existing migrations using South, and then have Django migrations take over. What might be the best way to go about this? If this is not possible or very much not recommended, what is the best alternative?
Maybe this post can help you. Essentially you have to:
Change your current migration directory from 'migrations' to 'south_migrations'
Update your settings with this line
SOUTH_MIGRATION_MODULES = {
'your_app': 'your_project.your_app.south_migrations',
}
I'm using sqlite3 and pycharm to learn more about django, and googled to find that south is recommended to make it easier to modify models after they have been created.
I'm trying to follow the advice on http://south.aeracode.org/docs/tutorial/part1.html#starting-off.
The most success I've had so far is to create a simple model and run syncdb before adding south to installed_apps. That way the intial tables are created and I get a chance to create a super user. (Django admin seems to fret if there are no users).
Then I add south to installed_apps, and run django_manage.py schemamigration bookmarks --initial
It seems to work fine. A new directory is created called migrations with a couple of files in it in my app folder and an encouraging message.
"Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate bookmarks"
The next step - django_manage.py" migrate bookmarks generates the following error message
django.db.utils.DatabaseError: no such table: south_migrationhistory.
I thought that table would be created in the first schememigration step. What am I missing? Can anyone help?
Marg
South uses a table if its own to keep track of which migrations have been applied. Before you can apply any migrations, this must have been created, using python ./manage.py syncdb.
As well as for setting up south, you will find syncdb sometimes necessary for non-south apps in your project, such as the very common django.contrib.auth.
Note that as a convenience, you can run both in one go like this
python ./manage.py syncdb --migrate
My latest (unsuccessful) effort was the following
Create application – synch db – superuser created
Test run –admin screen shows basic tables
Add south, and syncdb from command line with manage.py syncdb – south_migrationhistory table created. Add basic vanilla model
Tried various combinations of manage.py syncdb –manage, and
schemamigration from Pycharm (if run from within pycharm a
migrations directory is created within the app
– if run from the command line the directory does not seem to be
created.)
Django admin screen shows table – but if I try to edit
the table it says that it doesn’t exist
Check database structure
using SQLite browser - table for newly created model doesn’t exist
I’m starting to think that the whole thing is not worth the time wasting hassle – maybe I’m better off just modifying the tables in SQLite browser
Answer in the similar question:
Run syncdb to add the Django and South tables to the database.