On Wed, Mar 21, 2012 at 12:48 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
>
> On 21/03/2012, at 12:23 PM, Clay McClure wrote:
>
>> On Saturday, March 17, 2012 8:52:01 PM UTC-4, Russell Keith-Magee wrote:
>>
>> The only way I can see around this problem is to come up with a way for
>> ForeignKey(User) to transparently become an effective
>> LazyForeignKey('auth.User').
>>
>> I explored this a bit and found that, since the binding of
>> ForeignKey('auth.User') is already deferred, it would be straightforward to
>> defer binding of a model declared as "swappable", as you've suggested. My
>> concern—and the reason I opted to go the pluggable auth app route—was that a
>> deferred binding approach might also be needed in ModelForm[1] and model
>> inheritance[2]. Even then, we would still have apps that expect to be able
>> to use the User model they find at django.contrib.auth.models.User. I agree
>> that lazy foreign keys would be a welcome addition to Django, but it seems
>> to me we have some other problems to solve before they can replace auth.User
>> in a backwards compatible way.
>
> I agree - that's why my original proposal was to make the LazyForeignKey
> explicit -- that makes the adoption process opt in. Yes, this means that apps
> need to be modified and advertised to be "1.5 swappable-User-compliant".
> However, to my mind, that's a good thing, because you have an explicit marker
> that the author of the app expects the app to work with an User model, or
> that they've documented any specific requirements that the app needs to see
> in a swappable User object.
I'm +1 on the concept of configurable models and the LazyForeignKey,
as it solves the general problem of model class
reusability/flexibility. While the auth.models.User model is the most
common wart, I've come across plenty of instances where I would have
liked to more cleanly made use of particular models within a
third-party app that needed a bit of tweaking for a site's needs.
I'm not particularly thrilled about an explicit LazyForeignKey or
pluggable Meta class maker, though, because it requires that an
application author to actually make use of these features for an
application user to have the ability to extend any models the app has
defined. In other words, I don't want to have to ask your permission
to extend and reuse your model, thank you.
I propose:
3b) IMHO, if we are able to make a wholesale change in all of the
needed places (models, modelforms, etc.), then we just make ForeignKey
lazy by default. Unlike the other Solution 3 alternatives, it seems
that this could be made backwards compatible and also has the benefit
of requiring no code changes for third-party app authors.
3c) If we can't make the change all at once, or if it's decided that
making a model swappable really should be explicit, then perhaps an
alternate solution to the LazyForeignKey field or swappable Meta class
option proposals would be to introduce a new parameter to ForeignKey,
e.g.:
ForeignKey(User, swappable=True)
For backwards compatibility, the default would be swappable=False.
That way, if it were later decided that models should be swappable by
default, then we only need to change this parameter default to
swappable=True and any new/existing ForeignKey definitions
automatically get the new behavior (though behavior does not change
unless you've actually swapped out the model, of course). In this
scenario, app authors would still need to go explicitly make their
models swappable, but wouldn't need to make any further changes if the
swappable parameter default were to change.
Thoughts?
Gary
--
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.
