Re: The User mess
David Larlet
David
Le 15 sept. 08 à 01:38, Rodney Topor a écrit :
>
> I second this suggestion. I've struggled to decide whether to extend
> auth.User with a profile class with a reference to auth.User as
> recommended in the docs or by defining a superclass of auth.User.
> Each method has its pros and cons, but neither method is completely
> satisfactory.
>
> Rodney
>
> On Sep 12, 3:58 am, Dan Ellis <d...@remember.this.name> wrote:
>> First of all, congratulations to the team on reaching 1.0. It looks
>> like a lot of good features landed in time.
>>
>> One thing that I still find messy, though, is the whole user/profile
>> thing. Having separate models for users and profiles has a number of
>> drawbacks:
>>
>> * extra DB hits
>> * having to traverse either the user attribute or the result of the
>> get_profile method
>> * by default, the user information is split across two models in
>> the
>> admin interface
>> * the user, the profile, or both might need to be saved depending
>> on
>> which information was edited
>> * uncertainty over whether other models should have user or profile
>> as FK
>> * uncertainty over whether friendship relationship should be on
>> user
>> or profile
>>
>> Some people have suggested that the qsrf inheritance be used to
>> create
>> a model derived from User, and a custom authentication backend
>> written
>> that creates and returns instances of the appropriate model. I'm
>> fairly "meh" on that idea (and ORM-based inheritance in general, but
>> that's another story), and it doesn't seem to be a solution supported
>> by the official documentation.
>>
>> What I'd like to see is an easy, supported way of specifying the name
>> of the user model in the settings file, thereby avoiding all of the
>> above complexity. There are a few places where hard-coded references
>> to django.contrib.auth.models.User would need to be replaced, but I
>> can think of a couple of ways of doing that, including backwards-
>> compatible ones. Can anyone think of any reasons why this would be a
>> bad idea? I'd certainly be willing to provide a suitable patch.
> >
Dan Ellis
* Alternative user model is specified with USER_MODEL =
'myapp.models.MyUser'[1] in settings.py.
* Anything in Django itself that uses the User model can look this up,
but for backwards compatibility with apps,
django.contrib.auth.models.User should be a reference to this.
* The user model should physically live in (in terms of app_label,
position in the admin interface and database prefix) the app it is
defined in. Does that break anything?
* In the spirit of duck typing, the user model need only contain those
attributes that are needed in the application.
* There are a lot of utility methods in the existing User class. Does
that mean that instead of inheriting from just models.Model, the
alternative user class should also inherit from auth.UserMixin or
something?
What problems do people foresee here?
[1] Or ('myapp', 'MyUser')
David Larlet
Le 15 sept. 08 à 18:24, Dan Ellis a écrit :
>
> * If settings.USER_MODEL is not defined, nothing changes. Otherwise:
>
> * Alternative user model is specified with USER_MODEL =
> 'myapp.models.MyUser'[1] in settings.py.
Django "standard" is myapp.MyUser (as in AUTH_PROFILE_MODULE setting).
>
> * Anything in Django itself that uses the User model can look this up,
> but for backwards compatibility with apps,
> django.contrib.auth.models.User should be a reference to this.
>
> * The user model should physically live in (in terms of app_label,
> position in the admin interface and database prefix) the app it is
> defined in. Does that break anything?
>
> * In the spirit of duck typing, the user model need only contain those
> attributes that are needed in the application.
>
> * There are a lot of utility methods in the existing User class. Does
> that mean that instead of inheriting from just models.Model, the
> alternative user class should also inherit from auth.UserMixin or
> something?
Yes, some kind of BaseUser with Meta: abstract set to True which User
inherits from?
David
Dan Ellis
> Django "standard" is myapp.MyUser (as in AUTH_PROFILE_MODULE setting).
than in that variable? It's always struck me as an anomaly, which is
why either the Python namespaced name or two separate strings in a
tuple (therefore heavily resembling the arguments to get_model) seemed
more sensible. I was actually working on the assumption that in this
approach AUTH_PROFILE_MODULE would go away, but I suppose it would be
best kept for backwards compatibility for when USER_MODEL is not set.
> Yes, some kind of BaseUser with Meta: abstract set to True which User
> inherits from?
ABC stuff).
Carl Meyer
[1] http://code.djangoproject.com/ticket/3011
David Larlet
Le 15 sept. 08 à 19:27, Dan Ellis a écrit :
>
> On Sep 15, 5:32 pm, David Larlet <lar...@gmail.com> wrote:
>
>> Django "standard" is myapp.MyUser (as in AUTH_PROFILE_MODULE
>> setting).
>
> You say it's standard, but is that form actually used anywhere other
> than in that variable? It's always struck me as an anomaly, which is
> why either the Python namespaced name or two separate strings in a
> tuple (therefore heavily resembling the arguments to get_model) seemed
> more sensible. I was actually working on the assumption that in this
> approach AUTH_PROFILE_MODULE would go away, but I suppose it would be
> best kept for backwards compatibility for when USER_MODEL is not set.
It's used in get_storage_class:
http://code.djangoproject.com/browser/django/trunk/django/core/files/storage.py#L215
James wrote about that:
The reason is that Django is not using this to do a direct import;
instead, it’s using an internal model-loading function which only
wants the name of the app and the name of the model.
http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/
I'm not sure of the actual good practice for that.
Le 15 sept. 08 à 19:32, Carl Meyer a écrit :
>
> Seems like similar ground is being covered in #3011 [1]
You're right! It needs to be updated but that's it. Any thoughts from
core devs?
David
Marty Alchin
> It's used in get_storage_class:
> http://code.djangoproject.com/browser/django/trunk/django/core/files/storage.py#L215
I'm not following most of this discussion, but I should step in here.
get_storage_class expects a true Python import path, not the
app_label/model_name combination used for loading models. That puts
DEFAULT_FILE_STORAGE on even footing with MIDDLEWARE_CLASSES (where
the code was copied from, to be honest).
-Gul
Dan Ellis
> Seems like similar ground is being covered in #3011 [1]