[Django] #23498: V1.7 migration doesn't properly rebuild the through table from 3rd party library
Django
library
-------------------------------+--------------------
Reporter: variable | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23498>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
library
Reporter: variable | Owner: nobody
Type: Uncategorized | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* needs_better_patch: => 0
* resolution: => invalid
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23498#comment:1>
Django
library
Reporter: variable | Owner: nobody
Type: Uncategorized | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by variable):
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/23498#comment:2>
Django
library
Reporter: variable | Owner: nobody
Type: Uncategorized | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23498#comment:3>
Django
library
Reporter: variable | Owner: nobody
Type: Uncategorized | Status: closed
Component: Migrations | Version: 1.7
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by variable):
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/
--
Ticket URL: <https://code.djangoproject.com/ticket/23498#comment:4>