> On Sep 19, 2013, at 8:06 PM, Russell Keith-Magee <[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". >
But isn't that assuming your conclusion? The point we are making is that EmailUser *should* have the swappable Meta option. > Question: How does Django identify that EmailUser *shouldn't* be synchronised > to the database? EmailUser isn't mentioned in any setting (because > AUTH_USER_MODEL == 'auth.User'). There's nothing on EmailUser that flags it > as being a "User" model. It's in a models file with other models (Group, > Permission) which *will* be synchronized. Absent of any additional > information, EmailUser will be synchronised, because it looks like a normal > model. > > Answer: We have 2 options. We need to modify contrib/auth/models.py to read: > > class User(Model): > … > > if settings.AUTH_USER_MODEL == 'auth.EmailUser': > class EmailUser(Model): > …. No, you just add the swappable Meta option, and then it "just works" as far as the model is concerned, right? (I could test this...) > 1) We need to a bunch of internal plumbing in the app loader, Meta classes > and so on to determine whether or not a model should be synchronised, and > "hide" it in some way if it shouldn't be there. If you think this logic is > simple, I've got a bridge to sell you :-) This is where I think I must be missing something. Doesn't swappable already do this? If not, what *does* swappable do? > 2) We have to introduce a backwards incompatible change to pluggable models. > At present you don't have to pre-declare "my model is a User model". All > existing swappable User models in the wild need to be updated to be "1.7 > compliant". swappable is opt-in, not opt-out. Since existing models people are writing are not swappable, it would just work. The opt-in is to the ability to be subsumed if the setting does not match, not the ability to be used if it does. > Does that clarify the problem for you? Not really, to be honest, because your statements about how the existing system works are divergent from my observations. I am therefore very confused...even though I have mostly lurked here, I respect you highly and am inclined to trust your judgment. On the other hand, I can't figure out why your interpretation of the exists system is so different from what I seem to observe. Maybe you could help me with something: Could you explain to me what swappable *does* do? Here's what I think it does: I think it provides the mechanism to say, "do not use this model unless the setting says to use me". I infer from both you and Marc that's not what it does (Marc said I was proposing a "clever use"). That's fine. What does it do? Help me out. I feel certain I am just one step away from the lightbulb moment, but I really want to understand. I have the repo checked out, tests running, and want to work on this. But I want to make sure I do the best work possible, so I want to make sure I understand the problem space as much I can. Aim first, then fire, and all that. :-) L -- 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.
