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.
Related
I have a Django app with a model MyModel and some field my_field. My PostgreSQL database already has a field of that name under the mymodel table, since it was added manually in the past. When I make migrations, Django generates an AddField operation, which is in conflict. Currently I manually edit every generated migration to remove the conflict.
Is there a way to tell Django that the field already exists?
Unfortunately this is a live product, so I cannot lose any data.
Generate the migration that adds the field and then run python manage.py migrate <app_name> <migration_name> --fake to mark the migration as applied without actually running it
Thank you Iain Shelvington.
Is there any way I can use my default local database for testing in Django 1.9. I also don't want to run any migrations, and I want to test it locally.
The reason I want to do it this way is that in my migrations, I have a data migration referring to some entry from a model and when tests run and create a test_database the migrations fail as there are no entries in the test model and this data migration use .get()
I don't know how I should resolve this issue. The best way I could think of is my default database for testing.
I add custom fields in a model that require to be created in the order they are defined in the model. In the file created by the Django migration, this order is not respected.
Is there a way to tell Django makemigrations the order of operations ?
I use Django 1.8 and MySQL 5.7.
There aren't any options that you can pass to the makemigrations command to specify the order.
However, you can reorder the operations in the migrations file that is created.
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.
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.