I have a problem with migrations on heroku.
I have just upgraded version of django from 1.8.1 to 1.8.2 in my project on heroku, because of some missing migrations:
https://github.com/django/django/blob/1.8/django/contrib/auth/migrations/0005_alter_user_last_login_null.py#L14-L18
After this upgrade, on my local project I was forced to do standard procedure:
python manage.py makemigrations
python manage.py migrate
Of course this new, generated migrations are outside of my git repository. If I will run heroku run this will generate new migrations in new dyno, so without any impact on my current slug.
What is the best solution for this situation? How to generate migrations or add missing migrations of django or 3rd part libs when e.g. you are doing upgrade of the libs? What is the best working strategy?
Answer is quiet trivial, could be useful for others.
To use MIGRATION_MODULES is the correct answer.
https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-MIGRATION_MODULES
Related
To make a long story short: when I install django it comes with migrations that I deleted in the past.
Here is what I do:
$ mkvirtualenv foo
$ (foo) pip install django
Collecting django
Using cached Django-1.11.5-py2.py3-none-any.whl
Collecting pytz (from django)
Using cached pytz-2017.2-py2.py3-none-any.whl
Installing collected packages: pytz, django
Successfully installed django-1.11.5 pytz-2017.2
Now when I look in the directory where the venv is created I can see migrations in the default django apps (admin, user, ect.) I also see migrations in a brand new project.
This problems started after I tried to reset my migrations. I deleted the migrations from each app and dropped all the tables. Then I removed the migrations in the venv, while doing this I accidentally removed a django app. The missing app forced me to uninstall and install django.
Even when I tell pip not to use the cache --no-cache-dir, I still get the migrations.
This is by design. The default apps that come with Django need the tables created by those migrations.
If you don't need those apps, remove them from INSTALLED_APPS in settings.py.
I have, as usual the <project>/<app>/migrations folder that I added to the version control for deployment. Since recently I am also using django-auditlog, which creates its own migrations in <project>/env/Lib/site-packages/auditlog/migrations. These migrations are applied just like my own ones. So I wonder: should I also add them to VCS and deploy them?
No. You shouldn't deploy these migrations. In general you shouldn't deploy any third-party migrations.
The reason is simple. Third-party packages have their initial migrations inside their migrations directory. Each time you create a migration that depends on a third-party package, this migration will live in your app's migrations dir (not inside the package one).
So, when you first deploy your code and run pip install -r requirements.txt on your server, then all 3rd party packages will be installed and when you do ./manage.py migrate then Django will look at your INSTALLED_APPS and execute all migrations for each one in this list.
The same thing happens with any third-party package, just like Django itself. Suppose you have in your requirements.txt file only Django==1.10.6. When you deploy this to the server and do pip install -r requirements.txt, django-admin createproject myproject and then ./manage.py migrate, then your database will be "filled" with all Django-specific tables that has built-in (i.e auth, sessions, contenttypes etc) and are enabled in the INSTALLED_APPS setting list.
The one and only that you should deploy is everything under your project directory (requirements.txt, manage.py, robots.txt etc) and not your 3rd party apps which may live either inside your project (under a .virtualenv dir, probably) or in a separate .virtualenv dir outside of your project.
An analogous to your question is node_modules for nodejs. node_modules directory is never deployed to VCS (because it can get quite large in size etc), instead only the package.json is, because knowing what dependencies (package.json/requirements.txt) your project needs, then your project can "reconstruct" itself from zero.
In fabfile.py, I use something similar to the following to install dependencies and to migrate the changes to the new model
run("pip install -r ../deployment/pip/deploy.txt")
run("python manage.py migrate --settings=project.settings.prod")
When I upgrade the 3rd party apps which have migrations in the current version, but did not have in the previous one, my understanding is that I have to run ./manage.py migrate --fake <app_name>.
What would be a good solution with which a single deployment script (with Fabric) could pull the code from GIT repo, install new dependencies, take care of migrations and IF there are 3rd party apps that started using migrations recently, then run fake migrations on those.
Any pointers would be highly appreciated.
Thank you
I'm using Django==1.6.5 and djangorestframework==3.0.3 with South==0.8.4. And I am using virtualenv.
In settings INSTALLED_APPS I have both rest_framework.authtoken and rest_framework. Isn't the rest_framework.authtoken redundant?
When I run migrations it creates the migrations in my /Users/andi/.virtualenvs/my_virtualenv/lib/python2.7/site-packages/rest_framework/authtoken/migrations, which is of course not in my project's repo.
QUESTION:
How can I set up django rest framework to produce the migrations inside my project directory, so that, after running schemamigration locally, the only thing I have to run on server is migrate?
You are using django 1.6.5, in this version migrations were not introduced so its may give you error on running migrations because django rest framework auth token migration tries to import migrations from django.db
Upgrade your south package from 0.8.4 to 1.0.1 version that will solve your problem Please check the following link related to south version 1.0.1
http://south.readthedocs.org/en/latest/releasenotes/1.0.html
I'm working with a third-party Django package, and I'm not sure how to create a schemamigration. What's the equivalent of:
./manage.py schemamigration <app_name> when I don't have a ./manage.py?
While I don't think we can create South migrations without build a real django site(btw, you also need the django site for testing). Just treat your package like other django packages, and run schemamigration <your_app_name> to create migrations for it.
You only need to let django store migrations under your package's migrations directory instead of 'env/lib/pythonXX/site-packages/' You need to install your app with pip's editable” mode.
pip install -e local_path/to/your_package