On March 15, 2012, at 11:24 , Daniel Sokolowski wrote:
> Tom makes a good point, but you can already store emails in the username, > they are just limited to 30 characters or fewer. Lift this length restriction > and I will be able to do everything I need without having to wait for > contrib.auth2. In the 'I use django to make a living' world the solution > doesn't have to be perfect just good enough. The talk of lazy foreign keys > just so we can create contrib.auth2 just rubs me the wrong way, adds > additional complexity, and I see no benefit of it over a UserProfile model or > with model inheritance. > > And Django developer ought to be familiar how to do a schema migration for > this simple change, and if they fail to know instructions can be provided in > the release notes; there is NO need to have progress being stalled because > there is no built automated schema migration. > > Why can we not just increase the length limit on the username field?, Why > can't we just throw a validation error if data entered is to long and the > schema has not been updated? I think the answer yes we can and easily. Wouldn't increasing the length of the username field *also* incur a schema migration? After all, anyone who has spun up a Django site previous to the change would have a CHARACTER VARYING(30) (or a VARCHAR(30) or whatever the appropriate database-specific type is) in their database. So, we'd have a situation where Django would accept a 40 character email address, but then the database would truncate it or error out. The argument that Django developers ought to know how to do the schema migrations themselves seems poor to me. I expect some don't, and it's certainly a bigger backwards incompatible change than the Django development community has traditionally been comfortable with. Regards, Luke > > -----Original Message----- From: Tom Evans > Sent: Friday, March 09, 2012 11:46 AM > To: django-developers@googlegroups.com > Subject: Re: authentication by email > > On Fri, Mar 9, 2012 at 3:52 PM, Luke Plant <l.plant...@cantab.net> wrote: >> On 09/03/12 14:49, Tom Evans wrote: >> >>>> Yes, since no one needs it. Okay no one isn't true, but no one (for true >>>> this time) who needed it stepped up and said "I'll implement it and see >>>> that >>>> it ends up in trunk" >>>> >>> >>> I'm sorry, that completely mis-characterises the situation. Lots of >>> people want this, but every single time this has been brought up since >>> I started using django (1.0), a core dev or BFDL has explicitly ruled >>> it out, saying "we cannot do this, requires schema migration, we'll >>> look at it for the next version". >> >> This is not true. There have been times when we have said we cannot >> consider it right now, and that a solid proposal should be brought up at >> the calls for proposals for 1.1/1.2/1.3 etc., or at other times when the >> core developers can look at it. >> >> And every time, the proposal has either been missing or simply not been >> adequate - for example, the GSoC 2010 and 2011 proposals regarding this. >> Russell gave detailed feedback on why these solutions were not adequate >> [1], and at other times has provided feedback on possible strategies >> [2]. And the people who went away to work on the problem have gone >> silent or admitted defeat. One presumes they fixed their immediate >> problem in a way that would not be a general solution, and moved on, and >> that is perfectly understandable. A adequate solution to this is very >> hard, and probably requires solving several other big problems first >> (like at least one of lazy foreign keys/virtual models/database migrations). >> >> It isn't, however, impossible. Our definition of 'need' is that someone >> is sufficiently motivated to overcome the obstacles, and contribute a >> solution that works for other people as well as themselves. >> >> Regards, >> >> Luke >> >> >> [1] http://goo.gl/swTpr >> >> [2] http://goo.gl/7p1JN >> > > I disagree. There are small problems with the User model that have not > been fixed. Every proposal you've listed does not address these > issues, but instead looks to find ways of replacing the base user > object, which is a complex and difficult project. > > There is a reason why these are the proposals. Every time someone > proposes fixing these minor bugs, the cry from on high is that > instead, d.c.auth will be overhauled to allow for more customization > by the project, immediately increasing the scope and complexity. But > this fabled d.c.auth2 never appears. > > In fact, your reply alludes to this. We're talking about why a field > is too short to contain valid values, and you suggest that the > solution inevitably will involve "lazy foreign keys/virtual > models/database migrations" - it's changing one line, and adding a > comment to relnotes! > > We may have to agree to disagree on how easy some of these things are to fix. > > Lets look at one isolated aspect. The User email field in d.c.auth is > too short. Emails can be up to 248 characters long, and d.c.auth only > allows 75. > > Clearly, this is a bug, is wrong and should be fixed. How can we fix it? > > We can alter the length of the field in the model definition. What > problems does this bring? > > Users who do not manually update their database will not be able to > store longer length emails, and will get 'strange effects' when they > try - either silent truncation, or database integrity errors. How can > we mitigate this for users who refuse to update? > > Provide a compat shim that resets the email length to that in 1.3, and > immediately mark it PendingDeprecation. Users who read the relnotes > and don't want to change their DB can use the shim, and have a clear > expectation of when they must have updated their database. > > I still think these bug fixes are paralysed by a fear of change, and a > desire to engineer a solution that is every thing to every man. Lets > just fix these glaring bugs… > > Cheers > > Tom > > -- > 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. > > -- > 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. > -- 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.
