django-south

I have two classes, one of which is descended from the other, and I would like to make them both sibling classes descended from the same base class. Before: from django.db import models class A(models.Model): name = models.CharField(max_length=10) class B(models.Model): title = models.CharField(max_length=10) After: from django.db import models class Base(models.Model): name = models.CharField(max_length=10) class A(Base): pass class B(Base): title = models.CharField(max_length=10) When I generate a schema migration, this is the output, including my answers to the questions: + Added model

I have a short question about how to use Django-South while working in a team. What happens if two people simultaneously create migration file on changes to the same file? For example, A and B are working on same Django app. They are working in different branch and both at migration 005. Now, both A and B modifies apple/models.py and created migration file using startmigration. They are both at migration 006 but with completely different migration file 006. I guess when they merge their branches, there might be some error with South. Is there any workaround to resolve this conflict? Or is

I need to add a FULLTEXT index to one of my Django model's fields and understand that there is no built in functionality to do this and that such an index must be added manually in mysql (our back end DB). I want this index to be created in every environment. I understand model changes can be dealt with Django south migrations, but is there a way I could add such a FULLTEXT index as part of a migration? In general, if there is any custom SQL that needs to be run, how can I make it a part of a migration. Thanks. You can write anything as a migration. That's the point! Once you have South up and

Back in the days of South migrations, if you wanted to create a custom model field that extended a Django field's functionality, you could tell South to use the introspection rules of the parent class like so: from south.modelsinspector import add_introspection_rules add_introspection_rules([], ["^myapp\.stuff\.fields\.SomeNewField"]) Now that migrations have been moved to Django, is there a non-South equivalent of the above? Is an equivalent even needed anymore, or is the new migration stuff smart enough to just figure it out on its own? As Phillip mentions in the comments, deconstruct() is

I am using South with my Django app. I have two models that I am changing from having a ForeignKey relation to having a OneToOneField relation. When I ran this migration on my dev database, it ran fine. When the migrations get ran as part of creating a test database, the latest migration fails with a MySQL 1005 error: "Can't create table mydb.#sql-3249_1d (errno: 121)". Doing some Googling revealed that this is usually a problem with trying to add a constraint with the same name as an existing constraint. The specific line in the migration that it fails on is: The relation was changed from:

I have a Model class Mystery(models.Model): first = models.CharField(max_length=256) second = models.CharField(max_length=256) third = models.CharField(max_length=256) player = models.ForeignKey(Player) I added the player ForeignKey but when I try to migrate it using South it seems that I can't create this whith a null=False. I have this message : The field 'Mystery.player' does not have a default specified, yet is NOT NULL. Since you are adding this field, you MUST specify a default value to use for existing rows. Would you like to: 1. Quit now, and add a default to the field in models.py 2.

I have upgraded from Django 1.6.5 (with south migrations) to Django 1.8. I have followed the instructions here: https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south So, I remove South, delete my previous migrations and run python manage.py makemigrations which makes a new migration file. Then I run python manage.py migrate --fake-initial to fake the initial migration. Then I run python manage.py migrate . It all runs fine with no errors. I have a custom user model which inherits AbstractBaseUser . In Django 1.8 it seems there is a change to the last_login field where