You can manually edit your migration and add AlterField with default value for a field just before RemoveField. It should be safe even after applying migration. That will make RemoveField that will happen after to be reversible. An example. Having field in model summary named profit that was defined before removal like that: profit = … Read more
Simple specify many=True when creating a serializer from queryset, TaskSerializer(tasks) will work only with one instance of Task: tasks = Task.objects.all() serializer = TaskSerializer(tasks, many=True)
Found a blog post that reveals explicitly specifying TEST_RUNNER = ‘django.test.runner.DiscoverRunner’ in settings.py will stop this warning from occurring.
To answer your question, with the new migration introduced in Django 1.7, in order to add a new field to a model you can simply add that field to your model and initialize migrations with ./manage.py makemigrations and then run ./manage.py migrate and the new field will be added to your DB. To avoid dealing … Read more
If you are using your django project applications in standalone scripts, in other words, without using manage.py – you need to manually call django.setup() first – it would configure the logging and, what is important – populate apps registry. Quote from Initialization process docs: setup() This function is called automatically: When running an HTTP server … Read more
If you change the database, you should create database for the new database. Use manage.py migrate command. (or manage.py syncdb if you used it for old database).
So the step-by-step plan I outlined in my question does work, but instead of deleting rows from the south_migrationhistory database table, I had to delete rows from the django_migrations database table. The command is: DELETE FROM django_migrations WHERE app=’my_app’ Once this is done, you will be able to re-run your migrations from scratch.
Go to your database and find the table django_migrations. Delete all the rows which have app equals your app name. Then do a makemigrations & migrate will work.
The answer is: apps.get_model(‘contenttypes’, ‘ContentType’) 🙂 Needed it myself today.
You can squash it with the previous migration, sure. Or if you don’t want to output those migrations at all, you can override the makemigrations and migrate command by putting this in management/commands/makemigrations.py in your app: from django.core.management.commands.makemigrations import Command from django.db import models IGNORED_ATTRS = [‘verbose_name’, ‘help_text’, ‘choices’] original_deconstruct = models.Field.deconstruct def new_deconstruct(self): name, … Read more