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
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.
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
I am upgrading Django 1.4 to 1.8, and there are some 3rd party applications whose schema changed dramatically to support the upgrade. I want to reset these applications so I can recreate the corresponding tables from them. In the previous Django iterations, I can do either
./manage.py sqlclear appname
or
./manage.py reset appname
But both sqlclear and reset are already deprecated in Django 1.8. Is there a clean way to do this aside from manually erasing the tables from the database?
As of Django 1.8+ migrate appname zero unapplies all the migrations and deletes the tables docs
Take a look at Django Extensions, which give a slew of useful commands, including:
manage.py reset_db
https://github.com/django-extensions/django-extensions
Good luck!
Drop your Database and create it again its the fastest way !
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 am using django-south for migrating database tables in a django project. And I am renaming a model as discussed in a previous question:
# Renaming model from 'Foo' to 'Bar'
db.rename_table('myapp_foo', 'myapp_bar')
db.send_create_signal('myapp', ['Bar'])
However, I use fabric to automatically deploy my application to production servers, and I want the migrations to run without any user input. For this, I run the migration command with the noinput option as follows
python manage.py migrate --noinput
This works fine except that the send_create_signal does not remove stale contenttypes in this mode.
This is because the django contenttype managament command update_contenttypes only removes the stale contenttypes if input is given.
I could replicate the update_contenttypes command directly in the south migration, but that does not seem like a good solution. Does anyone have suggestions on how to trigger the removal of the contenttypes without repeating what is in the django command?
In my experience, running manage.py syncdb --all works some, but not all of the time when South is involved. You might try giving it a go, as it has worked for me in the past, certainly when removing stale models from the content-types table.