I understand migrate sets up the database according to the migration, but the scope of it's operation seems to go beyond that.
When I ran manage.py migrate, not only did it apply the database migrations, which is good, but it also went through the main url.py and started to execute the methods I had in there which I would like only to be executed only once when the "web starts".
What does migrate actually do?
Thanks!
migrate it is the django command, so when you run it through ./manage.py you also run django setup() and it validate(execute) project scripts.
Related
We are fairly new to Django. We we have an app and a model. We'd like to add an 'Category' object to our model. We did that, and then ran 'python manage.py makemigrations'.
We then deploy our code to a server running the older code, and run 'python manage.py migrate'. This throws 2 pages of exceptions, finishing with 'django.db.utils.ProgrammingError: (1146, "Table 'reporting.contact_category' doesn't exist")'
This seems to be looking at our models.py. If we comment out Category from our model, and all references to it, the migration succeeds.
I thought that the point of migrations is to make the database match what the model expects, but this seems to require that the model match the database before the migration.
We clearly are doing something wrong, but what?
I believe you skipped some migration in the server, so now you are missing some tables (I have been in that situation. Ensure migrations directories are on your .gitignore. You CAN NOT check in migrations files, you have to run makemigrations on the server). This can be solved by tracing back up to the point the database and models files match, but it is a risky process if it is your production database, so you should make a full backup before proceeding, and try the process on a different computer before.
This would be my advice:
Delete migration files from the server.
Comment the models that rise the error.
Set the server's migration history to the point the
database is, using python manage.py makemigrations and python manage.py migrate --fake-initial (this will update the migration files without actually attempting to modify the database).
Uncomment the models that raise the error.
Run python manage.py makemigrations and python manage.py migrate.
If, after you comment the models that raise the exception, you get a different exception, you have to keep on commenting and attempting again. Once a migrations succeeds, you can uncomment all commented models and make an actual migration.
Remember to run python manage.py makemigrations if you made changes to the models.py then run python manage.py makemigrations
Both commands must be run on the same server with the same database
one of my fellow developers checked out from master and created new models for our website. He ran makemigrations, then ran migrate which obviously created the tables we wanted.
However, he never committed his changes to github and he altered the production database. So when I went in to add a table today, when I ran makemigrations it the terminal listed several tables that I knew already existed...I was like "YOLO!" and ran the migrate command anyways and it puked.
So, since the migrations file isn't in my migrate folder, django thinks it needs to create those tables...then it goes to create them and pukes because they're already there.
The other developer is out of town visiting family and can't commit the file.
How do I get this set straight? I think I need to run ./manage.py migrate my_app --fake
But I don't completely understand what that does so I don't want to take the YOLO route and really mess things up...
OK, I promise everybody out there that I have been working on this problem for 9.5 hours today. Turns out this was the answer:
Django migrations : relation already exists
However, there were some spelling/syntax errors that made it difficult to understand that this other person had the same problem as me.
to reiterate the solution:
type: ./manage.py makemigrations your_app
Navigate to the my_app/migrations folder and open the migrations file that was just created (usually looks like '0005_modelsandstuff_blablabla.py"
Delete the models that DON'T ALREADY EXIST. Save the file and close
type: ./manage.py migrate your_app --fake
this will then sync what is in the database now with your models schema without altering any of the actual database
type: ./manage.py makemigrations your_app
type: ./manage.py migrate your_app
And that's it! Everything is all synced up again. Just as a quick jab I would like to say JavaScript sucks. Thanks.
Following these steps should solve your problem.
Backup your database
Stash your changes (so that only the missing schema changes are picked up)
Create the migrations (this creates the already applied schema changes)
Run migrate with --fake (this will fake apply the already done schema changes)
Apply your changes
Create the migrations
Run migrate
I deleted that table (whoops), and now I'd like to regenerate it. Is there a command that allows me to do that? Looking online, everyone is saying to use the command ./manage.py syncdb, but that command is no longer available in the most recent version of Django. So I tried ./manage.py migrate, but that didn't generate the table. I also tried ./manage.py --run-syncdb, but that didn't do it either.
I'm pretty sure I can do it by hand, but I'm hoping there's a way to do this with a built-in command.
Since the admin app only has one table, django_admin_log, you can revert all migrations for the admin app by running
python manage.py migrate admin zero
then re-apply the the admin app migrations by running
python manage.py migrate
You might want to create a backup before doing this (or any migration, really) :)
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.
I've been finishing up my first Django app and have run into a snag with migrations in Heroku. I migrated with South locally and then attempted to move those migrations to the database on Heroku.
When I ran:
heroku run stentorian/manage.py syncdb migrate report
I received the following error:
['/app/stentorian', '/app/.heroku/venv/lib/python2.7/site-packages/pip-1.1-py2.7.egg', '/app', '/app/.heroku/venv/lib/python27.zip', '/app/.heroku/venv/lib/python2.7', '/app/.heroku/venv/lib/python2.7/plat-linux2', '/app/.heroku/venv/lib/python2.7/lib-tk', '/app/.heroku/venv/lib/python2.7/lib-old', '/app/.heroku/venv/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7', '/usr/local/lib/python2.7/plat-linux2', '/usr/local/lib/python2.7/lib-tk', '/app/.heroku/venv/lib/python2.7/site-packages', '/app/.heroku/venv/lib/python2.7/site-packages/PIL']
Error: Command doesn't accept any arguments
I've researched this and can't seem to find how to resolve this. Prior to this, I installed the django-flaggit app to my application, which doesn't use migrations, and had to use a traditional syncdb to get the tables set up in Heroku. I'm wondering if this had an affect.
If anyone has any insight into this issue, it would be much appreciated.
What you are doing here is actully calling two different commands in a row: syncdb and migrate.
The usual workflow with south is to run syncdb to sync all your non-south-supported apps, and then migrate, to work on south-supported apps. Actually, if you just run syncdb with south installed, it will tell you which apps are unsynced and must be migrated.
So, to summarize:
heroku run stentorian/manage.py syncdb
heroku run stentorian/manage.py migrate report