V1.7 migration doesn't properly rebuild the through table from 3rd party library

[James Lin]

This is not necessarily a bug but would be great to have this working:

I recently installed ​https://github.com/adsworth/django-onetomany which adds an unique constraint in the through table, UNIQUE KEY referenceitem_id (referenceitem_id), see below:

| accounts_transaction_references | CREATE TABLE `accounts_transaction_references` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `transaction_id` int(11) NOT NULL,
  `referenceitem_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `referenceitem_id` (`referenceitem_id`),
  KEY `accounts_transaction_references_f847de52` (`transaction_id`),
  KEY `accounts_transaction_references_11805749` (`referenceitem_id`),
  CONSTRAINT `a_referenceitem_id_179ed3a0a0b94838_fk_accounts_referenceitem_id` FOREIGN KEY (`referenceitem_id`) REFERENCES `accounts_referenceitem` (`id`),
  CONSTRAINT `accou_transaction_id_7dafd9eb9684568c_fk_accounts_transaction_id` FOREIGN KEY (`transaction_id`) REFERENCES `accounts_transaction` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=latin1 |

Then I reverted to the standard ManyToManyField, ran the migration, but the unique constrain didn't get removed.

[Tim Graham]

I believe this needs to be addressed in django-onetomany as that is what provides the custom field with the extra constraint. Please reopen with more details if you don't think that's the case.

[James Lin]

I thought it would be nice for the builtin migration to remove any unnecessary constraints that are not used by the built in ManyToManyField.
Curious how would django-onetomany field address this one?

[Tim Graham]

I am not sure how it would work, but for Django to try to introspect indexes and remove any it doesn't expect seems dangerous. The field looks like somewhat of a hack. If possible, I would recommend using a ForeignKey instead.

[James Lin]

Yes a foreignkey would work but it reverse the dependencies of applications, eg. ​http://stackoverflow.com/questions/25635408/django-one-to-many-field-without-reversing-dependency
and ​http://blog.amir.rachum.com/blog/2013/06/15/a-case-for-a-onetomany-relationship-in-django/