I totally agree that we can't have a field on one model that modifies the underlying table of another model, especially with migrations in mind.
That said, I see value in a OneToManyField backed by a M2M with a unique constraint on one side. This is particularly useful when you don't want to modify a third-party app. Of course it can be done manually, but then the API isn't that great. Generalizing (documenting) swappable models could be another answer to this issue and yet it would probably be overkill for this purpose. -- Loic On Jun 16, 2013, at 12:04 AM, Carl Meyer <[email protected]> wrote: > The strongest reason not to do this is that it breaks the correspondence > between model fields and database columns. If you added a new OneToMany field > on Band pointing to Musician, suddenly the (unmodified) Musician model's db > table would require a schema migration, while the Band table would remain > unchanged. (Yes, ManyToManyField already sort of breaks this correspondence, > but only in that it causes a new table to be created in the same app where > you added the field. It never requires a schema migration for an untouched > model class, possibly in a different app, which is much worse.) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
