I've got a Zinnia install in my django 1.8 python 3.4 app that is throwing errors. I'm wondering if something changed in the model from when I intially ran the migration. However, I can't see to figure out how to start over and run the migration fresh.
These are the warnings I see when I try to do a makemigrations
WARNINGS:
zinnia.Entry.categories: (fields.W340) null has no effect on ManyToManyField.
zinnia.Entry.related: (fields.W340) null has no effect on ManyToManyField.
No changes detected
I see documentation on squashmigrations makemigrations and migrate. Is there a best practice way to remove migrations and start over fresh?
One way is to drop the db.
If you're using postgres,
then simply login to postgres account and dropdb <db> and run migration again.
Another way is to flush the db.
You can do this by ./manage flush which will flush all the data in your db.
If you're using sqlite3 then, just remove db.sqlite3 from your project root.
Related
I modified a model field in my local environment and made the migrations. Every thing seemed fine until I pushed it to production. I tried to apply the migrations to my DB and received an error:
cannot ALTER TABLE because it has pending trigger events
I ended up just reverting to the previous migration, which solved the problem for now.
But now I have these unapplied migration files pending and I need to find a way to either delete them or ignore them. What is the best solution moving forward?
Local
Production
You can fake the problematic migration (documentation here) - and then run the rest of the migrations.
Should be:
python manage.py migrate --fake 000x_problematic_migration
And then run the rest of the migrations
python manage.py migrate
I have a django 1.8 app working with a db.
I'm trying to change the schema of a table using the built-in migration.
Here are the steps I did:
In my dev invironment, I grabbed the app source and ran
python manage.py sycdb
then I ran
python manage.py loaddata ~/my_data.json
then I modified modes.py. Added a field and renamed a field...all from the same table 'TABLE1' which had no data.
then
python manage.py makemigrations myapp
python manage.py migrate
Error: django.db.utils.OperationalError: table "myapp_someother_table" already exists
then ran
python manage.py migrate --fake-initial
worked!
but when I browsed to the admin page for TABLE1, I get this error:
OperationalError: no such column: myapp_table1.my_new_field_id
I checked the db and yes, there is no such column.
How can I procceed from here? I prefer to fix this via django.
If I fix it straight in the db, then the migration goes out of sync.
Migrations do not automagically see that you have made changes. Migrations detect changes by comparing the current model with the historical model saved in the migration files.
In this case, you didn't have any historical models, since you didn't have any migrations. Django was not able to detect any changes in your models, even though they were different from your database.
The correct way to make changes to your model is to first run manage.py makemigration <my_app>, and then make the changes to your model, followed by another manage.py makemigrations.
You might not be able to do it via pure django and keep your data. I don't have personal experience with south but there are a lot of mentions if this tool. Just in case if nothing else works for you...
Here is what I did to make things work, but there must be a better way so please add more answers/comments...
I deleted the sqlite db and the migration folder
I made the desired changes to model.py
ran syncdb
ran loaddata to load the json data dump that I had saved previously.
just started the dev server
I have Django 1.7 running on Heroku. I've made a change to the models.py file (added a column to a table) but Django doesn't seem to be able to detect this. When I run
python manage.py makemigrations appname
it responds No changes detected in app.
I've tried deleting the appname/migrations folder, but that doesn't help.
Is there a way to get Django to rescan the database and check for differences? This was easy with South.
https://docs.djangoproject.com/en/1.7/topics/migrations/#the-commands
Have you tried
python manage.py migrate
It seems the migrate is "responsible for applying migrations, as well as unapplying and listing their status."
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'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.