On Sat, Sep 25, 2010 at 1:47 PM, Carl Meyer <carl.j.me...@gmail.com> wrote: > Hi all, > > I've seen some level of interest in the idea of a lazy foreign key > (one whose target table is determined by project configuration in some > way, not hardcoded by the app/model in which it lives). The idea was > most recently brought up again in Eric Florenzano's keynote at > DjangoCon. I have some ideas regarding possible API for this, and > would be glad for feedback. > > First, a couple motivating use cases: > > 1. Reusable apps overuse GenericForeignKey. GFKs are inefficient and > smell bad. They're good to have around when you really need to link to > any one of a possibly-growing set of models. But currently reusable > apps often use them anytime they want to link to "some domain model > but we don't know which one" - even if in practice in most cases it > will be only one! A lazy foreign key would be a better solution. > > 2. Standardization with flexibility: i.e. possible-future replacement > of contrib.auth.User. To be clear, I am not at this point proposing > any changes at all to contrib.auth. But in some future possible > contrib.auth refactoring, a lazy foreign key could provide a way for > reusable apps to point to a common User model, without Django having > to provide a concrete implementation of that model. > > The concept: > > We introduce the "virtual" model, which is an abstract model with the > following additional characteristics: > > - It can be the target of a ForeignKey. > - It may only have one direct concrete subclass, and if it is the > target of any ForeignKey it must have exactly one. > > At runtime, any ForeignKeys pointing to a virtual model are resolved > to actually point to the concrete subclass of that virtual model. > > Like an abstract model, a virtual model may include fields, methods, > etc. These can be considered the specification of an interface: any > model with a ForeignKey to this virtual model can expect the concrete > model to satisfy that interface. This is particularly helpful for a > contrib.auth-type use case: reusable apps don't only need a User model > to point FKs at, they also often need at least some minimal set of > fields/properties they can rely on being present. > > It's not required for the virtual model to have any fields, of course: > in some use cases (voting, tagging) the reusable app doesn't need to > know anything at all about its target model. A hypothetical voting app > could simply provide an empty "VotableObject" virtual model, which > would be inherited by the domain model which can receive votes. Since > Django already supports multiple inheritance for abstract models, this > is a minimal and non-restrictive requirement for the domain model > author. > > Advantages of this proposal: > > 1. No new settings. > 2. In terms of new code API, almost nothing: a new "virtual = True" > Meta keyword. > 3. Very little conceptual overhead; reuses existing constructs as much > as possible. > > I plan to put together a patch to show working code for this, but I'd > be glad for any feedback at this point, especially if there are > obvious conceptual problems I'm overlooking. Thanks! > > Carl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > >
ISTM this would solve the "auth.User" issue, but doesn't help reusable apps at large: one can trivially imagine a project that wants voting (or tagging ;), or commenting, or ...) on more than one model. In any event, my brain needs to digest (and I need lunch), Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
