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.
Related
I have a table containing a list of subclasses of a certain class in my django app.
How can I make django require a data migration when this table is edited ?
Is there some exception I can raise if django is started and one of these classes isn't in the table ?
I'd also like to be able to hook into makemigrations so I can generate the correct data migration if possible.
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.
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.
As I want to customize Django user model, I migrated from default user model to my own custom user model. Since my Django project has been working since a long time ago, I need to keep the existing user data.
I was thinking to move them manually, but Django default user model's passwords are hidden. How can I safely move existing user data to my custom user model?
Moving to CustomUser is no easy task in Django. If you want to keep the existing data, then as per ticket #25313, you need to do the following steps:
Create a custom user model identical to auth.User, call it User (so many-to-many tables keep the same name) and set db_table='auth_user' (so it uses the same table).
Throw away all your migrations from all the apps(except for __init__.py file inside the migrations folder).
Recreate a fresh set of migrations(using python manage.py makemigrations).
Make a backup of your database.
Delete all entries from django_migrations table from DB.
Fake-apply the new set of migrations(using python manage.py migrate --fake).
Optional: Set db_table="your_custom_table" or remove it altogether.
Make other changes to the custom model, generate migrations, apply them.
You can dump your existing model data with dumpdata command and also able to reload those data to that model or your changed custom model with loaddata command. Here is a good example how you can able to do that. link
I want to generate SQL code and take from that code, generating a Django model to avoid errors.
They will say that you first create the model and run the syncdb or migrate but my case is unlike the database is already created and I now want the model
Run this command to auto-generate models from an already existing database. But first make sure you've properly linked database to django app .
python manage.py inspectdb > models.py
Do check models.py file and make some changes if you something isn't rendered correctly.
For inspectdb approach, read this: https://docs.djangoproject.com/en/1.8/howto/legacy-databases/
Alternatively, you can write all the models by yourself and set managed = False. No database table creation of deletion will be executed by Django on this model. But it is somewhat complicated and puts some limits on model relationships.
For managed=False approach, read this: https://docs.djangoproject.com/en/1.8/ref/models/options/#managed