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. Carl -- 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.
