On Fri, Mar 9, 2012 at 3:23 AM, Danny Adair <danny.ad...@unfold.co.nz>wrote:
> It's the "required" of username that's the problem if you don't want a > username at all when authenticating against email. > It would have to be not required and check required fields in clean() > where the backend could be asked what's really required. > That's one problem. Another problem is that the default User.email field is not unique, is not required, is not indexed, and may be too short. And there's Mr. Schema Migration again... > Who's talking about a migration? I'm asking for something that will work for *new* installations; existing installations can continue authenticating against usernames for all I care :) Moreover, I'm thoroughly frustrated by the fact that developers *do* bring working solutions to the table (in the form of patches in trac), but the core developers won't integrate them, either because it's not the right time (usually right before a release), because the patch isn't general enough, or because the patch doesn't meet some absurdly high bar of quality. I understand that they have a commitment to backwards compatibility and that accepting a mediocre patch could mean maintaining it for life, but I like to think that—with a framework that purports to be "pragmatic"—there are pragmatic solutions to these problems—and not, "sorry, it's not perfect, it can't go in." The GSoC page ( https://code.djangoproject.com/wiki/SummerOfCode2011#Enhancedauth.user) is a frustrating read. It goes on and on about how hard the problem is and how wrong your solution is, but doesn't provide any detail as to why it's hard or why it's wrong. Ticket #3011 was rejected without much of a reason. HM asked for an explanation both in the ticket itself and on django-dev; no explanation was ever given. The GSoC page also mentions migrations: "How can we roll out a new/modified User model without requiring almost every Django application on the planet to undergo a complex database modification?" But again, why do existing databases have to change? We're talking about leaving User as-is, by default, but providing a mechanism to use a different model if the developer chooses. Clearly this is a decision the developer would not take lightly: you're not going to change from username authentication to email authentication without a bit of thought. Projects that are using username authentication will continue to use username authentication, but at least new projects that want/need email authentication will be able to do that without monkey patching models. The GSoC page also mentions Lazy Foreign Keys, but no explanation is given there or in the linked django-dev thread as to why LFKs are required to implement a pluggable User model. LFK may be the panacea of code cleanliness and virtual awesomeness, but those of us with deadlines just need to authenticate against email addresses, like, five years ago. Cheers, Clay -- 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.
