LazyForeignKey will not solve any problem that can't be solved now, and we have to introduce a new concept. It sounds like, when we encounted a hard problem, we give it a new name, instead of trying to solve it. Moreover, to support multiple user models, each app should be able to link to a different user model, LazyForeignKey can't be any help. Maybe the only way to solve this is to add a schema migration tool. When schema migration tool found a ForeignKey link to a different model than before, it raises a error, then I know there is something wrong.
On Apr 5, 8:45 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On 05/04/2012, at 12:20 AM, Adrian Holovaty wrote: > > > > > > > > > > > On Wed, Apr 4, 2012 at 9:57 AM, Jacob Kaplan-Moss <ja...@jacobian.org> > > wrote: > >> On Wednesday, April 4, 2012 at 9:44 AM, Russell Keith-Magee wrote: > > >> My point is that there is nothing about this problem that is unique to > >> User. > >> Django's own codebase contains another example of exactly the same pattern > >> -- Comments. > > >> As the original author and designer of that pattern, I should probably > >> point > >> out that I now think it's a mistake. Have you actually tried using it? It > >> doesn't really work very well. Every time I've introduced any sort of > >> "swappable model" mechanism I've come to regret it. > > > Totally agree with Jacob here, plus Tai's comment that "There is such > > a thing as too generic." We've made the mistake of making things too > > generic in the past, and it's kind of infuriating in retrospect, both > > philosophically and in terms of code maintenance/understanding. > > (django/utils/tree.py, anyone??) > > > I think our policy should be: make the simplest thing that can > > possibly work for a narrowly-tailored use case, then make things more > > generic *slowly* if there's a demand. No need to be an Architecture > > Astronaut. > > Certainly agreed that astronauting is a bad thing. > > However, I would like to draw attention to one particular benefit of the > generic solution (other than being generic): > > Once we make User swappable, every app with a model that has a ForeignKey to > User will need to be updated. This can be done slowly; existing projects that > use auth.User will continue to work. However there won't be any real alert to > the fact that the app requires updating until you try to swap out User and > things start to break. This breakage will be somewhat unpredictable -- you'll > just be observing side effect errors as a result of a non-existent (or empty) > auth_user table. > > Under the approach I described, User will be marked (in the Meta object) as > swappable, and ForeignKey(User) will be a hard link to a swapapble model, > which is something we can catch as a validation warning, providing a cue to > developers that there are apps in their project that may need to be updated. > And if there is a ForeignKey(User) and settings.USER_MODEL *isn't* User, then > we can raise an validation error, because we know that this app won't work. > > Even if we don't implement a fully generic solution, I think this property of > the generic approach is worth preserving. > > Yours, > Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
