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 django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
