I have two databases configured, one for all but one tables, table, which I have in the second database, database2. I store data, and retrieve data perfectly without using any router, just the 'using' attribute on the save and the get. I was upgrading our app to django 1.8 a while ago, and it seemed to be working, table in database2 doesn't change that often, but it has been working ok since the upgrade.
But now I need to make a change to table in database2.
So I try manage.py migrate table --database database2. The migration seems to take, but I get an error in the end.
RuntimeError: Error creating new content types. Please make sure contenttypes is migrated before trying to migrate apps individually.
I've been trying to add contentypes and auth as fake migrations in database2, but I still get the error. Will adding a router make it go away? Are there any other ways?
Thanks!
Related
We have a django app that is running in production.
It used to run django 1.4.3 against a mysql database.
We had all our migration scripts using django south.
We recently upgraded to django 1.11.6. Along with it we moved the data to a postgres database.
The app runs fine, but the migration scripts that are generated using django migrations by using the django models are not fully consistent with the existing schema.
Almost all of the differences seem to be in the index names that are generated.
What are our options to make the django migrations and the database consistent? How do we go forward with this?
Should we generate a new empty database using the django migrations, and migrate the data from the old to the new empty database?
I know we can edit the models.py and set the index names manually but that is too cumbersome, we need to edit hundreds of models; is there an easy way to do that?
Is there a way I can generate the migration scripts from the existing database, and verify if the models are compatible?
I run migration on server in this way:
Upload models.py file to server with some new field sfield im model Mobject
Perform makemigration command in manage.py
perform migrate command in manage.py
But there are some requests between end of first step and end of third step which are failed with django.core.exceptions.FieldDoesNotExist: Mobject has no field named 'sfield' (Which is obvious, becouse django ORM can't fetch this field from DB but field already in Class, so django will try to do it)
Is it possible to make all 3 steps "Atomic"? Or globaly ignore this exceptions, becouse for now I don't need sfield, I only want perform migration without Exceptions. Or may be I can temporarely mark new field in some way to prevent django fetching it from DB, but it must be visible for makemigrations/migrate?
if you do select * from yourtable then django tries to fetch all fields defined in the model.
you can use only() in your orms to select specific fields, so that no exception will be raised while migrating new fields that are not used in orm yet
btw, you should create migration files locally, test the new field on your local machine and then commit the migration files to server. In server while deploying, you then need only migrate right after deployment, which makes the time shorter where exceptions can happen.
from the django docs:
The reason that there are separate commands to make and apply
migrations is because you’ll commit migrations to your version control
system and ship them with your app; they not only make your
development easier, they’re also useable by other developers and in
production.
Have created almost all of my models and I get this error in one model in particular (not all of them).
Error creating new content types. Please make sure contenttypes is migrated before trying to migrate apps individually.
It occurs when I'm accessing the model through Django admin. I am have NOT migrated from one version of Django to another - so the contenttypes table does not have the 'name' column. It has the fields id, app_label and model.
I have tried migrating contenttypes. Some apps I can migrate others will throw the same error I see in the browser accessing the model in the admin page.
Any ideas or help would be appreciated!
Python version is 2.7.6
Database - Postgres 9.3
UPDATED QUESTION 12/7/15:
I seem to be running in circles - getting several errors related to this issue.
Here is another error I get in trying to resolve this issue:
Programming Error: Permission denied for sequence django_migrations_seq
(when trying to do a fake migration)
Programming Error: relation "employees_employee" already exits
(when trying to run a normal migration)
3 of the Models I'm having an issue with are database views (not actual tables).
This seems to be a combination of a postgres and django error - not one or the other. No idea what to do at this point - keep going in circles between these errors.
Have checked all permissions, grants, etc... all is good there.
Thanks!
I created my database using python manage.py syncdb And I tried to add another attribute to my model called created_date My site gives error. And I deleted my db.sqlite3 file Then reorganize my model Then error went. I want to know is this correct
As the comment says migrations are the way to do this. Native migrations were only introduced in Django 1.7 but, since you're using syncdb, I'm guessing you're using an earlier version.
For earlier versions of Django you need a third-party app called South to handle migrations for you. This will then let you change your database after creation fairly painlessly in most cases.
I am working on a Django project where I have to use South to migrate one application to another. I have the old internal message application which I have to replace by another completely different. I was wondering if I could pass by orm, but the old application doesn't exist anymore in the INSTALLED_APPS, so no sense. Does using a SQL procedure is the way to do that? I'd like to keep the application DB type independant at the time.
Django applications are namespaced in the database so you ought to be able to temporarily have both applications installed. I would break it down to about three migrations:
A schemamigration to add the new application. If other applications need to have foreign key relations to the new application, add those and just make sure they are all nullable.
A datamigration to walk the model objects in the old application and create the equivalent ones in the new application.
A schemamigration to remove the old application.
schemamigration: python manage.py schemamigration myapp (with nullable foreign keys)
datamigration: Django custom sql is my friend -> https://docs.djangoproject.com/en/dev/topics/db/sql/
have made my custom data migration script keeping the project DB independent
remove the old application schema using 2.
(optional) a backwards rescue script