On 04/04/2012, at 10:57 PM, Jacob Kaplan-Moss 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.
>
> I'm -1 on the idea of generalized "swappable model" mechanism. I can stomach
> it for User because in this context it's not any worse than the alternatives,
> but as a generalized mechanism it makes me really, really unhappy. Decoupling
> is a laudable goal, but providing a mechanism to reach in and effect code not
> under your control isn't good design. We use derisive terms like
> "monkeypatching" for a reason.
Agreed that monkeypatching is bad. However, I think that's the wrong analogy in
this case; I think "interface" is a closer match.
An interface is essentially just a way of saying "I need to operate on an
object with these properties, but I'm going to let the end user define the
specific object instance that provides those properties". As a language, Python
generally doesn't need interfaces because of duck typing. However, ForeignKey
is a "strongly typed" database relationship, so you can't duck type it -- the
original app developer needs to be able to define it as something that the end
developer might want to change.
> I'm sure there are good reasons for wanting swappable models. Russ, I know
> you're smarter than me,
Don't put too much weight in that argument. I have plenty of braindead ideas.
The PhD just means I'm persistent :-)
> so the fact that you want LazyForeignKey so much probably indicates that
> you've got some really solid use cases in mind. But really this is a hard
> veto from me; I just can't be convinced that this sort of mechanism is
> anything but bad news.
To tell the truth, I haven't used the comments app extensively, so I can't
really comment on that example specifically. I also don't have a specific case
in mind where I want to use this feature. However, if you think of the problem
being solved here as interfaces, it isn't hard to think of other possible
applications.
More broadly, my reaction comes from the the fact that I *have* been bitten --
many times -- by claims that "this is a special case". Special cases almost
never are, and the counterexample usually shows up a week after you're
irretrievably committed to a "specialized" solution.
> However, I don't see why we should actively prevent this sort of thing being
> done externally, so if there's anything in Django that's precluding the
> creation of a LazyForeignKey as an external add-on let's consider that
> limitation a bug and get it fixed.
Sure -- I can live with that. There's really only two places where I see this
being an issue in practice:
1) Introducing UserField(). I'd be against introducing UserField() as a
special case of ForeignKey(). Even though it's more typing,
ForeignKey(settings.USER_MODEL) offends me less. This doesn't preclude other
developers writing their own ForeignKey shortcuts; I just think it sets a bad
example.
2) The synchronization/app cache problem. In order to do this properly, we
need to prevent the auth_user table from being created, and auth.User being
added to the app cache. If we're going to address this by adding hooks into the
model startup process, I'd like to see them as general hooks, rather than
special cases for auth.User -- even if they're undocumented hooks.
Of course, the other option is just an if statement in the models.py file:
if settings.USER_MODEL == 'auth.User':
class User(models.Model):
username = ...
which is a pattern that other uses could adopt.
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.
