Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#23498 closed Uncategorized (invalid)

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

Reported by: James Lin Owned by: nobody
Component: Migrations Version: 1.7
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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

I recently installed 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` (
  `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`)

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

Change History (4)

comment:1 by Tim Graham, 10 years ago

Resolution: invalid
Status: newclosed

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.

comment:2 by James Lin, 10 years ago

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?

comment:3 by Tim Graham, 10 years ago

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.

Note: See TracTickets for help on using tickets.
Back to Top