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.
Related
In a Django project, I have a few apps and one model-class will be created in one app's models.py and imported to another apps' models.py. then I run migrate for each app per one schema in Postgres, there is no error reported.
But the issue is the shared model will be migrated to all the schemas because (I assume this is the reason) I imported this model in each app's models.py.
Anyone knows How to avoid or solve this problem. Because I would like keep the model only stay in his original schema.
Or can I delete this model directly from each schema it appears?...without any side effects.
Please help, Thanks!
I found a better answer: Installing PostgreSQL Extension to all schemas.
should see this before.
Accidentally found the solution, just use 'public' schema for the app where models supposed to import to other apps.
Just for someone who experience the same situation.
I have a Model file which has a change which isn't being picked up by DJango makemigrations.
I created a manual migration following this answer, but if we run makemigrations afterwards Django creates a new auto migration reverting our manual changes.
Is there a way to manually make a migration and tell DJango to ignore relevant parts of the code when generating future migrations?
After making changes to the models and creating a custom migration for them e.g. using RunPython or RunSQL you can use the state_operations argument to reflect the changed models' state in your custom Python or SQL operations.
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?
The issue at hand is that in order to install default data into the database for built-in django applications such as flatpages or auth.group requires specifying SOUTH_MIGRATION_MODULES although the South documentation isn't very clear regarding the directory structure and the way to generate such data migrations.
Any ideas how to do this?
It's not necessary to use South for this, you can use an initial fixture which is auto loaded when you do a syncdb:
https://docs.djangoproject.com/en/dev/howto/initial-data/#automatically-loading-initial-data-fixtures
The docs do note that from Django 1.7 onwards this is deprecated (in fact syncdb itself is deprecated) and you should make a data migration using the new built-in migrations functionality, which supersedes South:
https://docs.djangoproject.com/en/dev/topics/migrations/#data-migrations
If you want to use South migrations for say django.contrib.auth.models.Group then I think you can do it like this:
/projectroot/
/projectroot/myapp
/projectroot/myapp/migrations
/projectroot/myapp/migrations/__init__.py
/projectroot/myapp/migrations/auth/__init__.py
/projectroot/myapp/migrations/auth/0001_initial_groups.py # arbitrary name
(any structure that results in a sane Python dotted import path to your actual migration from your project code)
Then in settings:
SOUTH_MIGRATION_MODULES = {
'auth': 'myapp.migrations.auth',
}
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