On Fri, Sep 20, 2013 at 10:53 AM, <gavinw...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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