Model validation requires that ForeignKey be unique (backwards-incompatible change)

[Jeff Balogh]

This was changed in [12756] for #11702. As stated in the description for #11702, MySQL and SQLite are ok with non-unique ForeignKey fields.

Much to my chagrin, our MySQL app relies on this. I know it's wrong, but it's what I have to work with right now. The table I'm using has a uniqueness constraint on a pair of fields, not just the ForeignKey. I override the pieces that expect uniqueness, but for the most part the ForeignKey machinery just works.

We were fine until validation got more strict.

[Luke Plant]

It's not clear what bug you are reporting.

The change was a deliberate decision. Django's ForeignKey is many-to-one, and if it happened to work in other cases that was unintended and unsupported. If you are suggesting that this is listed as a backwards incompatible change, I would respond that this is in the category of every other bug fix - you were unfortunately relying on the previous buggy behaviour. In this case, since your Model will not validate you will be alerted to the change very quickly (i.e. it will be impossible to run your code), so it will add very little value and a lot of text to add this to the release notes.

So I'm afraid you are stuck with 1.1, or finding other ways to patch up your model and code, sorry.

[Gabriel Hurley]

@jbalogh, without seeing your code it should be possible to fix what you're relying on... since misusing ForeignKeys is no longer an option you'll need to rewrite the block of code that no longer validates, but I assume your larger concern is with database structure. Thankfully MySQL has robust support for the ALTER TABLE statement. You should be able to update your tables in a non-destructive manner when you decide you do want to update to 1.2 for production.

[Jacob]

Milestone 1.2 deleted