Hmm. It seems to be database-specific. PostgreSQL and Oracle require that foreign key references be unique, while MySQL and SQLite do not (although for SQLite that's mainly due to it not actually implementing foreign key constraints). The MySQL documentation has this to say:
>> Additionally, MySQL and InnoDB require that the referenced columns be >> indexed for performance. However, the system does not enforce a requirement >> that the referenced columns be UNIQUE or be declared NOT NULL. The handling >> of foreign key references to nonunique keys or keys that contain NULL values >> is not well defined for operations such as UPDATE or DELETE CASCADE. ... which we never do, because it's a temporal database. It does recommend that they be unique anyway though. I'll file a bug with Django to make the validate command require that foreign keys reference unique columns, and to update the documentation to actually say that the to_field should be unique. In the meantime I'll have to make a reference field that supports foreign key semantics (e.g. book.author and Author.book_set) that doesn't actually subclass ForeignKey. :/ Thanks, Nick On Aug 11, 10:00 pm, Malcolm Tredinnick <[email protected]> wrote: > On Tue, 2009-08-11 at 12:00 -0700, physicsnick wrote: > > Actually they don't need to be unique (and I don't want them to be > > unique). MySQL does not require that foreign keys be unique; only that > > they be indexed. > > > I am actually using this for a temporal database. There are many > > instances of an Author with the same code (an instance for each time > > it was changed). In relation to the above example I am having the > > Author's default manager filter for live instances of the object, and > > making it be used to resolve foreign keys via "use_for_related_fields > > = True". This means the reverse relationship (book.author) gives one > > object: the live version of the author with the referenced code. While > > the foreign key itself is a many-to-many relation at the database > > level, > > Django's ForeignKey field is many-to-one. The fact that it happens not > to raise an error when you twist it slightly in the way you're doing > doesn't mean it's expected to work. > > I'm not convinced there is a bug involved here, since you're not using > the ForeignKey class correctly. As far as I can work out, when > ForeignKey is used correctly, we always are going to be generating the > correct SQL. > > I thought Django's "validate" management command raised an error when > to_field was used to target a non-unique field, but apparently I'm > hallucinating. That's probably an oversight in the implementation. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
