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.
