25👍
-
Create your intermediate model without any extra fields, for now. Give it a unique constraint to match the existing one and specify the table name to match the existing one:
class CategoryEntry(models.Model): category = models.ForeignKey(Category) entry = models.ForeignKey(Entry) class Meta: db_table='main_category_entries' #change main_ to your application unique_together = (('category', 'entry'))
-
Run the South schema migration.
-
Edit the generated schema migration script and comment-out all the forwards and backwards entries, since you’ll be re-using the existing intersection table. Add
pass
to complete the methods. -
Run the migration.
-
Update any existing code. As it says in https://docs.djangoproject.com/en/dev/topics/db/models/#many-to-many-relationships, “Unlike normal many-to-many fields, you can’t use add, create, or assignment to create relationships” so you’ll need to modify any existing application code, e.g.
c.entry.add(e)
could become:
try: categoryentry = c.categoryentry_set.get(entry = e) except CategoryEntry.DoesNotExist: categoryentry = CategoryEntry(category=c, entry=e) categoryentry.save()
and:
e.category_entries.add(c)
could become:
categoryentry = CategoryEntry(category=c, entry=e) #set extra fields here categoryentry.save()
and:
c.entry.remove(e)
could become:
categoryentry = c.categoryentry_set.get(entry = e) categoryentry.delete()
-
Once this initial pseudo migration has been done, you should then be able to add the extra fields to the
CategoryEntry
and create further migrations as normal.
34👍
In Django 1.7+ built-in migrations, the way the “code state” (i.e. the code definition of models) is calculated is different, and requires a different solution.
In South (Django pre-1.7), the entire “code state” is saved in each migration — but in Django 1.7+ built-in migrations, it’s derived from looking at the whole set of migrations, so you need to specify the “code state” change in a migration without altering the database.
Like above, this will need to be done in a few steps.
-
Create an intermediate model like in the answer above:
class CategoryEntry(models.Model): category = models.ForeignKey(Category, on_delete=models.CASCADE) entry = models.ForeignKey(Entry, on_delete=models.CASCADE) class Meta: db_table = 'main_category_entries' #change main_ to your application unique_together = ('category', 'entry')
-
Create an auto-migration with
django-admin.py makemigrations
and modify the code; move the operations list into thestate_operations
argument of amigrations.SeparateDatabaseAndState
operation, and leave thedatabase_operations
list empty. It should look like:class Migration(migrations.Migration): operations = [ migrations.SeparateDatabaseAndState( state_operations=[ migrations.CreateModel(CategoryEntry..) ... ], database_operations=[] ), ]
-
Edit the
CategoryEntry
to contain what you want and create a new auto-migration withdjango-admin.py makemigrations
- [Django]-Convert an IP string to a number and vice versa
- [Django]-Django – form has no errors but form.is_valid() doesn't validate
- [Django]-How are Django channels different than celery?
5👍
The Django documentation has this exact case as an appplication of the migrations.SeparateDatabaseAndState operation. I did exactly what the documentation said but Django kept throwing an exception saying that the table used for the M2M mapping didn’t exist.
I was assigning a table name through the “db_table” attribute of the Meta class of the intermediary model and this was causing the problem (don’t know why).
I then understood that the SQL code shown in the example in the Django documentation is to change the name assigned by Django to the M2M relationship table in the standard M2M relationship to the new name assigned by Django to the table corresponding to the intermediary model used.
database_operations=[
# Old table name from checking with sqlmigrate, new table
# name from AuthorBook._meta.db_table.
migrations.RunSQL(
sql='ALTER TABLE core_book_authors RENAME TO core_authorbook',
reverse_sql='ALTER TABLE core_authorbook RENAME TO core_book_authors',
),
],
In this example, “core_book_authors” is the old name and “core_authorbook” is the new name of the M2M relationship table. If you do not include this code in the migration, you won’t be able to add extra fields to the intermediary model (and I assume this is the main reason to have a custom M2M relationship) as Django will look for the new table name.
To sum up what I did to change a standard M2M relationship to a custom one using ‘through’:
- Created intermediary model without the extra fields (only the two foreign keys) and specified that the M2M relationship was now to be made via that model (using ‘through’).
- Run command
py manage.py makemigrations
. I changed this autogenerated migration to look like the one in the documentation referenced above. - Run command
py manage.py migrate
. - Added all the extra fields that I needed in the intermediary model.
- Run command
py manage.py makemigrations
. - Run command
py manage.py migrate
.
The table that previously represented the standard M2M relationship will now have a different name and all the new columns. It is important that these columns have a default value if you already had data in the table.
I find this to be the most straightforward way to do this WITHOUT losing any data.
- [Django]-Making a Regex Django URL Token Optional
- [Django]-How can reference the last item in a list in a Django template? {{ list.-1.key }}
- [Django]-Why don't my Django unittests know that MessageMiddleware is installed?
4👍
I’d do it in the following way:
-
Add the
CategoryEntry
class to the model, and do an auto schema migration. This will add an empty table containing the properties ofCategoryEntry
. To be noted, the older M2M table remains untouched sincethrough='CategoryEntry'
has not yet been added. -
Do a data migration to copy all data from the existing M2M table to the table created in step 1. To do so, run the
datamigration
command, and edit methodsforward()
andbackward()
in the auto generated migration script accordingly. -
Now add
through='CategoryEntry'
part (just the way you wanted), and do a schemamigration. this will drop the old M2M table.
- [Django]-Retrieving parameters from a URL
- [Django]-Django, filter by specified month and year in date range
- [Django]-Elastic Beanstalk could not find any platforms