Yes it clearly would, however I see two possible solutions to make it more
friendly:
1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - I
mean the actual commands to execute.
2. Catch the DB error and throw a form validation warning for those that
didn't.
-----Original Message-----
From: Luke Sneeringer
Sent: Thursday, March 15, 2012 12:28 PM
To: django-developers@googlegroups.com
Subject: Re: authentication by email
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.
--
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.
