It's less efficient because of the extra table but that's pretty much the only option when you need a FK on a model that you can't edit. GFK are not exactly efficient either, yet most will agree that it's sometime the best option to a given problem.
I agree that the distinction between FK and O2M might be a little confusing to newcomers but I think it can be addressed with sufficient documentation. I would work on a patch if we have an accepted ticket. -- Loic On Jul 11, 2013, at 7:13 AM, Carl Meyer <[email protected]> wrote: > On 07/10/2013 05:40 PM, Carl Meyer wrote: >>> I'm not sure I completely agree with Carl that is breaks correspondence >>> -- after all, m2m fields don't correlate to a field, either. However, in >>> the absence of a built-in migrations framework, I suspect a O2M field >>> would be a pretty efficient foot-gun for newcomers. >> >> I mentioned the m2m case in my email. The more basic invariant (that is >> currently respected by all built-in fields) is "when you put a field on >> a model, it creates or changes db tables in that model's app, not some >> other app." >> >> What's being requested here is essentially an ORM variant of >> monkeypatching third-party apps. While I accept that monkeypatching >> third-party code is sometimes pragmatically the best of bad options, I >> don't think it's a technique that we should be blessing with a built-in >> first-class field type. > > Er, never mind all this. I missed that the latest version of the > proposal is for an M2M-like table with a unique constraint on one side > of it, rather than adding a real FKey to the remote table. In that case, > this "monkeypatching" objection doesn't apply. > > It's still a slightly unnatural (and less efficient) way to model the > data, even if useful in some cases; not sure it meets the barrier for > inclusion in core, but we can see how it works out externally. -- 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.
