On Fri, Sep 20, 2013 at 10:53 AM, <[email protected]> wrote:

> > Note that EmailUser *doesn't* have a Meta: swappable definition. There
> is nothing on this model that says "I am swappable", or "I am an
> appropriate substitute for User".
>
> Ah, this is were the misunderstanding was. authtools does actually set
> swappable on its replacement user, too[1]. The two definitions look like
> this:
>
>     class User(Model):
>         username = models.CharField()
>         USERNAME_FIELD = 'username'
>         class Meta:
>             swappable = 'AUTH_USER_MODEL'
>
>     class EmailUser(Model):
>         email = models.CharField()
>         USERNAME_FIELD = 'email'
>         class Meta:
>            swappable = 'AUTH_USER_MODEL'
>
> > How does Django identify that EmailUser *shouldn't* be synchronised to
> the database?
>
> The existing swappable mechanism takes care of it. Only the model
> referenced by settings.AUTH_USER_MODEL will be installed, not both.
>

Ah. Thats… interesting. I'm moderately surprised it works at all. I'll need
to dig in to the internals to work out *why* it works… swappable certainly
wasn't intended to work like that. There might be some interesting land
mines lying in wait.


> > we still have a problem -- We can't just say
> "contrib.auth.forms.AuthenticationForm", because this form needs to change
> depending on the model that is in use. We have similar problems with admin,
> and potentially with views and URLs.
>
> It's straightforward to make the forms, views, and URLs work without
> checking what user model is installed, and this is the approach authtools
> takes. We can agree that code like `if settings.AUTH_USER_MODEL ==
> auth.EmailUser"` is absolutely awful, so it's nice that it's not required
> to implement forms that work with custom user models. The forms from
> authtools will work with any user model, not just authtools.User and
> auth.User.
>

Well… no, they won't. They'll work with a *very* wide subset of User
models, but not *every* user model. Most notably, you're relying on the
ModelForms providing the right widgets for all fields, which will be a
valid assumption for *most* models, but not *all* models. Given that Django
aims for a 90% solution, I'm not sure that this is a major problem, however.

What *is* a major problem is the issues you'll have with tests. Your code
binds User -- and thus the forms -- at import time. You're going to have
fun using those forms in a test environment that is swapping User models.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to