Extend support for long surnames in Django Auth

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Hello everyone,

For a long time I was having problems to login to djangopackages.com using my github account (pydanny/djangopackages#338). After investigating I discovered the problem was because my surname is longer than 30 characters. I don't know why both first_name and last_name fields have the same size limit of 30 characters in Django. That doesn't sound very reasonable.

I'm sure there are other people on the same situation and this already happened with me trying to login in other django websites.

Tim Graham suggested I should first ask on this maillist (https://github.com/django/django/pull/6988#issuecomment-235945422) to see if there is consensus to make the change.

I would like to ask your opinion about an increase from 30 to 60 characters on last_name field so that my login and others won't break again in the future. I can create a Trac ticket if the response is positive.

Kind Regards,

[Erik Cederstrand]

Hello Raony,

I'm sure I'm not aware of all the implications of changing the field length, but the first question should be "how long is long enough"? In answering this question, this Quora question comes to mind: https://www.quora.com/Why-are-South-Indian-names-often-long

Kind regards,
Erik
a.k.a. Bommiraju Sitaramanjaneyulu Rajasekhara Srinivasulu Laxminarayana Siva Venkata Sai :-)

> Den 29. jul. 2016 kl. 09.18 skrev Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas <raonygu...@gmail.com>:
>
> Hello everyone,
>
> For a long time I was having problems to login to djangopackages.com using my github account (pydanny/djangopackages#338). After investigating I discovered the problem was because my surname is longer than 30 characters. I don't know why both first_name and last_name fields have the same size limit of 30 characters in Django. That doesn't sound very reasonable.
>
> I'm sure there are other people on the same situation and this already happened with me trying to login in other django websites.
>
>
>
>
>
>
>

> Tim Graham suggested I should first ask on this maillist (https://github.com/django/django/pull/6988#issuecomment-235945422) to see if there is consensus to make the change.
>
> I would like to ask your opinion about an increase from 30 to 60 characters on last_name field so that my login and others won't break again in the future. I can create a Trac ticket if the response is positive.
>
> Kind Regards,
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/56bc25d9-372e-4985-b601-3cce9664160c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Aymeric Augustin]

Hello,

Indeed, Django’s default limit on last name length doesn’t work well for Brazilians (at least).

Actually having a `first_name` and `last_name` field doesn’t work well in various cultures, including the US when you want a middle initial. Custom user models are the general answer to that question.

In this particular case, the drawbacks of increasing the `max_length` of `first_name` and `last_name` to something like 50 seem limited now that we have the migrations framework. Making that change will automatically avoid the issue for many people — perhaps at the cost of introducing UI issues when the name is displayed in the header, but that’s arguably a lesser evil.

So I’m +0 on making that change.

--
Aymeric.

> On 29 Jul 2016, at 09:18, Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas <raonygu...@gmail.com> wrote:
>
> Hello everyone,
>
> For a long time I was having problems to login to djangopackages.com using my github account (pydanny/djangopackages#338). After investigating I discovered the problem was because my surname is longer than 30 characters. I don't know why both first_name and last_name fields have the same size limit of 30 characters in Django. That doesn't sound very reasonable.
>
> I'm sure there are other people on the same situation and this already happened with me trying to login in other django websites.
>

> Tim Graham suggested I should first ask on this maillist (https://github.com/django/django/pull/6988#issuecomment-235945422) to see if there is consensus to make the change.
>
> I would like to ask your opinion about an increase from 30 to 60 characters on last_name field so that my login and others won't break again in the future. I can create a Trac ticket if the response is positive.
>
> Kind Regards,
>
>
>

[ludovic coues]

The W3C have some recommandation on the question.

https://www.w3.org/International/questions/qa-personal-names

2016-07-29 17:47 GMT+02:00 Aymeric Augustin
<aymeric....@polytechnique.org>:

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4A15ED67-802B-4A3A-85DA-265A5A5ADEF1%40polytechnique.org.

> For more options, visit https://groups.google.com/d/optout.

--

Cordialement, Coues Ludovic
+336 148 743 42

[Aymeric Augustin]

Hello,

I usually build my projects upon these recommendations, but the UX is awkward and the end result tends to be short_name = first_name and full_name = first_name + space + last_name.

We could discuss the usefulness of providing an alternate user model that has short_name + full_name instead of first_name + last_name but in my opinion that’s another discussion.

Best regards,

--
Aymeric.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTZXuGBr4_eU5pHBUONX8k5Z-z13YApJOxH%3D4iWbPutArA%40mail.gmail.com.

[James Pic]

Indeed first and last name dont make sense en various culture. In the Memopol project for exampe where wé have a table of European Parliament representative we have all sorts of names including (The Earl Of) name suffix which is part of the reasons our first / last name system was completely checkmated.

Nowadays I just go for a single and long name field and I would like to suggest that django.contrib.auth takes this path too because the first name and last name system isn't international and django is for building websites on internet which is meant to be a communication tool connecting Humans of the world, no matter if they have a first and last name or not.

[Josh Smeaton]

> Nowadays I just go for a single and long name field and I would like to suggest that django.contrib.auth takes this path too because the first name and last name system isn't international and django is for building websites on internet which is meant to be a communication tool connecting Humans of the world, no matter if they have a first and last name or not.

I think having a single name field is reasonable for the vast majority of cases, but it fails where projects really do need to identify two names for things like sorting or categorising. I'd be willing to argue that if you did need to differentiate between parts of a full name then you could customise your User model to account for that. The issue is backward compatibility. We can't just use migrations to remove the last name field because that would break working code and potentially delete data. It'd break a lot more than simply increasing the size of existing labels.

I'm +0 on increasing the length of first name and last name. 

Separately but related - I'd be interested in a discussion around what Django could do to encourage new projects to always customise their user model. Something like having the startproject command include a models file containing a user model ready to be customised, and the setting AUTH_USER_MODEL correctly pointing to it (perhaps with switches to switch between different user models?). So many people run into issues by not customising their user model right at the beginning of their project, and we get into positions where users are unable to properly fix problems they have with the user model and ask for modifications to the default user model like we're seeing here. 

Regards,

Josh

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Hello all, here are my thoughts after reading the discussion.

@Erik You won on having the biggest name! Regarding your question about "how long is long enough", after checking other web frameworks such as rails (http://stackoverflow.com/questions/3354330/difference-between-string-and-text-in-rails), I believe the most sensible proposal would be to increase from 30 to 255, which is the maximum value permitted for a varchar without changing any field in User model.

@Aymeric Agree with you that now with the migrations framework this would not be a big issue. Regarding the UI, I argue that this is something we already have to deal with, for example, if someone uses all 60 characters for first_name and last_name (Ex. "Bommiraju Sitaramanjaneyulu Rajasekhara Srinivasulu L S V Sai")  this will probably already break the UI in most cases. We can always use {{ last_name|truncatechars:30 }} to fix the UI. I mostly believe we should delegate this to the developers of each app and not to the users (Ex. that have big surnames).

@Ludovic, is_null and Josh Thank you for the link and suggestions. I agree that "Full name" seems to be the most reasonable choice here, but I don't want break backwards compatibility, or at least not on this proposal. :)

So I'm suggesting a change from 30 to 255 characters on last_name field, which is the maximum possible without breaking backwards compatibility. Maybe on Django 3 we can propose a change to "Full name" field ?

Kind Regards.

[Florian Apolloner]

On Saturday, July 30, 2016 at 3:25:35 PM UTC+2, Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas wrote:

So I'm suggesting a change from 30 to 255 characters on last_name field, which is the maximum possible without breaking backwards compatibility. Maybe on Django 3 we can propose a change to "Full name" field ?

Technically this is breaking backwards compat, ie there might be other apps out there expecting not more than 30 chars as a result of Django's limitations. I'd rather see a proposal which does it right before we migrate once again. Ie migrate first_name + last_name to full_name and add a display_name or similar which saves how a user wants to be addressed. This also fixes issues with titles and whatnot.…

Cheers,
Florian

[Aymeric Augustin]

Hello,

> On 30 Jul 2016, at 10:52, Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas <raonygu...@gmail.com> wrote:
>
> So I'm suggesting a change from 30 to 255 characters on last_name field, which is the maximum possible without breaking backwards compatibility.

I’m -1 on basing the decision of “how long a last name does Django allow by default” on an unrelated technical limit. We’re discussing how long a reasonable last name is, not how many bytes MySQL can fit in a varchar without incurring an extra byte of overhead for storing the string length.

I have trouble believing that a significant number of people are used to typing 100+ characters when inputting their name into a website — let alone that a significant number of people have a last name that contains more than 100 characters and that isn’t a joke. How would it fit on a passport?

I know that Brazilian last names are commonly in the 30-50 characters range. Going for 60 to have a bit of margin makes sense. If my estimate is too low, we could go even further. But 100 and above doesn’t make sense to me.

If you want to allow 255 characters in last names, in my opinion, you’re in the territory of custom user models.

> Maybe on Django 3 we can propose a change to "Full name" field ?

There’s a misconception about “Django 3” here. Django will guarantee the same compatibility between the last 2.x version and 3.0 than between 2.(x-1) and 2.x.

Apart from that, I think that the most reasonable path to a built-in User model not based on first and last name is to ship a new model next to the current one and suggest that developers point AUTH_USER_MODEL to that model — or, even better, that they inherit the abstract version of the new built-in model in their project and point AUTH_USER_MODEL to their copy, so that they can make changes later if needed.

Best regards,

--
Aymeric.

[Donald Stufft]

> On Jul 30, 2016, at 4:40 PM, Aymeric Augustin <aymeric....@polytechnique.org> wrote:
>
> I have trouble believing that a significant number of people are used to typing 100+ characters when inputting their name into a website — let alone that a significant number of people have a last name that contains more than 100 characters and that isn’t a joke. How would it fit on a passport?

See #6 of https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

—
Donald Stufft

[Tim Allen]

+0 to extending the length, but the 255-character maximum in MySQL shouldn't be a concern since MySQL 5.0.3 (IIRC). I'm all for the ease of a length increase to the concern raised in the original post. While it would be nice to do more in the long term, that's a bigger discussion, as Aymeric points out.

I think it is also worth noting that creating a one-to-one UserProfile model or AbstractUser is significantly less intimidating to a newcomer and easier to change down the road than attempting an AbstractBaseUser implementation. Would it also be worth increasing the length of the `username` field to make email as username implementations easier, while we're on the topic?

While Florian bring up some good points as well, there are years and years of legacy examples on the subject out there (Stack Overflow, for one) beyond the documentation that might make the larger change more appropriate for 2.0.

Warm regards,

Tim A.

[Shai Berger]

See #11 of this list. If we were to take it seriously, any name field should
have an accompanying charset field. Or, actually, some substring-to-charset
mapping, because of #10. Which makes one just go straight to #36.

It isn't really a workable set of constraints.

However, since you brought it up, and since it mentions names from the Klingon
Empire, I would like to remind the supporters of MySQL-driven limits that for
encodings which can express the full range of Unicode, including Klingon and
Emoji, the MySQL limit is 191 and not 255. Just sayin'.

Shai.

[James Pic]

On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton <josh.s...@gmail.com> wrote:
>
> I think having a single name field is reasonable for the vast majority of
> cases, but it fails where projects really do need to identify two names for
> things like sorting or categorising.

I'd be willing to believe that a project requires storing names as an
array of words for sorting. I can see how that would be helpful to do
sorting. Even I have a full name of 5 words and I only use two of them
because it's my culture. In this situation how to convince someone
that it's not a waste of time to have to fill in several form fields,
when they are going to the usage name they want anyway which is
conceptualized rather as an array of words than a pair of words. Some
people won't even want their real name on some projects.

> I'd be willing to argue that if you did
> need to differentiate between parts of a full name then you could customise
> your User model to account for that. The issue is backward compatibility. We
> can't just use migrations to remove the last name field because that would
> break working code and potentially delete data. It'd break a lot more than
> simply increasing the size of existing labels.

Deporting the issue on the user project is an option, but I'd like to
suggest that we keep on trying to find a curative solution for this
issue which has been brought up on regularely. It should be possible
to make a migration to add and provision the full name column and make
first and last name column read-only if they exist - but not be
provided on new projects. Even then, the backward incompatibility will
be an easy fix, it's not like we were splitting data the other way,
that would be a lot more difficult and require esoteric code, again,
just like when we try to make people fit in two distinct inputs.

Free users from our culture, open django.contrib.auth to the world.

Rock'on

James B)

--
http://yourlabs.org

[Curtis Maloney]

As I watch this discussion I am reminded of a talk I saw a few years ago
at PyConAU:

https://www.youtube.com/watch?v=_V4q0o-nKp4&list=PLs4CJRBY5F1KDIN6pv6daYWN_RnFOYvt0&index=33

--
Curtis

[Aymeric Augustin]

> On 30 Jul 2016, at 23:15, Donald Stufft <don...@stufft.io> wrote:
>
> See #6 of https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

I’m aware of this article. It's a entertaining read but, unlike the W3 Q&A mentioned earlier, it doesn’t contain actionable advice for designing a generic system that won’t perform too poorly in many use cases when you have no idea of what these use cases will be.

Once you reject the idea that “People have names”, it’s pointless to discuss modelling of name fields. If you merely reject the idea that “People’s names are all mapped in Unicode code points”, it’s still pointless to discuss how many code points names usually contain.

So let’s stay focused on a practical design, let’s do something that most people will find reasonable, and those who don’t can use custom user models.

Last names containing over 30 characters are sufficiently common — likely tens of millions of people at this time — to deserve consideration. That’s where this thread started. Let’s not block an easy win for these tens of millions because the general problem is intractable. Besides, a last_name field is already a severe simplification, as we all know.

Last names containing over 100 characters are sufficiently uncommon to be the subject of trivia articles on the Internet. I’m absolutely certain that no website has tens or thousands of millions of last names over 100 characters; in fact, not even tens of such names.

If someone has access to real-life stats from a very large database of names in a country that has long last names that could help us make an optimal decision.

If we can’t find that information, let’s go for max_length=60 and commit the change.

--
Aymeric.

[James Pic]

Aymeric, it doesn't matter if tens of milions of names fit into your
model, it only takes one to have a issue that's going to require the
project developers to invest time in it. So I'm a bit lost about
what's the most practical approach here.

[Michael Manfre]

I agree with Aymeric. Short of actual stats stating otherwise, I think we should use max_length=60 and accommodate most people on the planet out of the box without a non-trivial amount of time/effort. For those who want to go above an beyond for a handful of potential users, they can create a custom User model; bonus points if they make it a reusable app or even a gist.

Regards,

Michael Manfre

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALC3KaeTBeRU-S2Kk_639ikFP7Z7rxc7LAV17qcDfHM63ATh%3Dw%40mail.gmail.com.

[Aymeric Augustin]

Hello James,

> On 01 Aug 2016, at 15:03, James Pic <jame...@gmail.com> wrote:
>
> Aymeric, it doesn't matter if tens of milions of names fit into your
> model, it only takes one to have a issue that's going to require the
> project developers to invest time in it.

I’m not an adept of the “worse is better” school of thought. I believe that fixing the problem for 99,9999% of people while not creating new problems for anyone matters.

There will always be cases where django.contrib.auth doesn’t work ideally. What matters is the ability to argue that a particular case is enough of an edge case not to be worth dealing with, and the person who finds themselves in that case to expect and accept that answer. Clearly “name over 30 characters” isn’t sufficiently rare to meet this criterion. (It was fine when it just had to work for LWJ’s staff.)

Some organizations will have a cost/benefit approach to this question. Making the problematic cases less frequent reduces the chances that the benefit of fixing them justifies the cost. Then developers don’t have to invest time in it. Other organizations will reject the notion of cost and have a more philosophical approach; that’s harder to discuss in general but solving a problem while not introducing any new problems still makes the situation better for them. At the very least they get a better base to build upon.

Anyone who likes using an absurdly long last name, for whatever reason, and enjoys typing it just to get a “name too long” error message on every website knows how to fix it: use a subset of their name. They’re already doing it whenever they fill a form, whether on paper or on screen. Paper forms usually don’t have room for writing names on multiple lines.

Can you just let use improve the situation for tens of millions of Brazilian users? It doesn’t cost you, or anyone else, anything. Just let us make things better for tens of millions of people and not make them worse for anyone.

To be extremely clear, let me repeat once again: I’m not trying to make django.contrib.auth to work for everyone, I know that it still won’t work for everyone and I accept that my proposal doesn’t attempt to solve the problem of names entirely. It has been abundantly explained in this thread why it’s impossible to do something that works for everyone anyway. If we wanted to do something that worked for significantly more people, we’d start by dropping the first / last name fields. You’re welcome to make a proposal in that direction, but I would kindly ask you to do it a a new thread and let us solve that stupid name length problem for tens of millions of Brazilian users in this thread.

> So I'm a bit lost about what's the most practical approach here.

Per my definition of “practical”, fixing 99,9999% of a problem with a very small effort like I suggested is a practical approach.


--
Aymeric

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Dear all,

I kind of agree with Aymeric, increasing last_name to max=60 characters would already be good enough for this proposal and should cover 99.99% of users without breaking backward compatibility.

I support your idea of a built-in User model not based on first and last name. But that sounds too much of a challenge for me at the moment.

I'm also missing some data to back up this claim, but 30-50 characters for last_names in Brazil sounds about right. I will check some databases I have access, but my opinion is that this is already going in a good direction!

Thank you all for the support and discussion.

Kind Regards.

_____________________________________________

Raony Guimarães Corrêa Do Carmo Lisboa Cardenas
PhD in Bioinformatics

email: raonygu...@gmail.com
skype/hangouts: raonyguimaraes
phone: +48 722 148 478

_____________________________________________

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ED879BC4-F89D-48D6-9B09-2778FBDBF998%40polytechnique.org.

[Malcolm Box]

On Monday, 1 August 2016 13:56:55 UTC+1, Aymeric Augustin wrote:

> On 30 Jul 2016, at 23:15, Donald Stufft <don...@stufft.io> wrote:
>
> See #6 of https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

I’m aware of this article. It's a entertaining read but, unlike the W3 Q&A mentioned earlier, it doesn’t contain actionable advice for designing a generic system that won’t perform too poorly in many use cases when you have no idea of what these use cases will be.

Having read the W3C Q&A carefully, the relevant comment on field lengths is "avoid limiting the field size for names in your database". There is no reference to 60 characters being "enough".

 

Last names containing over 30 characters are sufficiently common — likely tens of millions of people at this time — to deserve consideration. That’s where this thread started. Let’s not block an easy win for these tens of millions because the general problem is intractable. Besides, a last_name field is already a severe simplification, as we all know.

Last names containing over 100 characters are sufficiently uncommon to be the subject of trivia articles on the Internet. I’m absolutely certain that no website has tens or thousands of millions of last names over 100 characters; in fact, not even tens of such names.

If someone has access to real-life stats from a very large database of names in a country that has long last names that could help us make an optimal decision.

Aren't we in danger of premature optimisation here? The field lengths are currently 30 characters. Even if we expanded it to 255, we would be adding at worst 255 bytes to the storage requirements for a user. If a site has 1 million users, that's 250MB of disk space - which for a site with 1M users is unlikely to be significant, let alone the main driver of disk usage. After all, with 1M users, you'd only need each of them to do something requiring a 200 byte record to use the same amount of space.

For sites with far less users, it's proportionally much less of a problem - and those sites are the majority, and hence will benefit most from being able to deal with more user's names, while suffering the least cost. Sure, we'd be wasting some space on disks - but we'd be enabling Django to serve more of the world's population (and allowing sites to just use last_name as a full name if they don't want the fun of a custom user model).

So if we don't want to go to full TextField for the username, at least let's go to the biggest number possible (currently 255, thanks MySQL).

Premature optimisation is the root of all evil...

Cheers,

Malcolm

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Hi Malcolm,

It seen everyone here agree 30 characters is not enough for last names and this should be changed. I also think 255 characters would cause less trouble in a sense, cause we wouldn't have to deal with this problem again until we decide to go full TextField. which is actually the best decision (IMHO).

Regarding breaking the UI, I prefer a website with a broken UI than a website I cannot login (Ex. with my github account) because of my name. Lesser of two evils.

So how we could reach a consensus between 60 and 255? 60 will cover my last name, but not erik's ... I wish we could solve this for everyone and not only for me ... :/

Kind Regards.

[Aymeric Augustin]

Hello Malcolm,

> On 02 Aug 2016, at 10:28, Malcolm Box <mal...@tellybug.com> wrote:
>
> Having read the W3C Q&A carefully, the relevant comment on field lengths is "avoid limiting the field size for names in your database".

Indeed. I chose to propose something else because I didn’t want the solution to depend on an implementation of “CharField of unlimited length”.

That feature isn’t hard to implement but it involves more difficult design decisions. Look at the archives for this mailing-list for more information.

Anyway, it seems that this issue is bound to die in a bikeshedding fest, so I’ll leave it there, with my apologies to Brazilian users who will remain unable to log into Django-based websites :-(

--
Aymeric.

[Malcolm Box]

Hi Aymeric,

I'm sorry that you feel this has devolved to a bikeshedding fest, that certainly wasn't my intent, and I'd hate to see this issue die. I think we both agree that supporting people's names is important - which is the main thing.

To summarise the available options discussed so far:

Status Quo: Do nothing, and fail to handle a large chunk of the world's population who's names don't fit in 30 characters

Radical changes (in order of increasing radicalness):

 - Change fields to a TextField

 - Replace last_name / first_name with a single "name" field

 - Change startproject to default to a custom user model with default fields that are in line with W3C recommendations

Minimal change: Increase the length of the existing fields

As far as I can see, everyone is in favour of the minimal change option NOW, and possibly some of the Radical changes later.

So the only remaining disagreement is over the value of max_length to change to. Proposals of 60, 100 and 255 have been made.

If I created a patch that set the max_length to 255, would anyone object? If so, what's the objection - storage space shouldn't be a concern, and breaking a form seems as likely with 60 as 255?

Cheers,

Malcolm

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/36DD2C84-E5ED-4646-9857-B6BC5D92BE94%40polytechnique.org.

[ludovic coues]

Someone mentioned mysql not supporting nicely string of 255 unicode characters.

> You received this message because you are subscribed to the Google Groups

> "Django developers (Contributions to Django itself)" group.

> To unsubscribe from this group and stop receiving emails from it, send an

> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/CAF3R4sU%3D1gaTk3AGRY7nuQHFX8op9-b00Frc6z_1k69k_R-bNA%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

[James Pic]

Thanks for your reply Aymeric. If I understand correctly the best way to approach this, besides increasing the current limits - which I've had to do myself a few times - is to create a separate app providing a custom model with an ArrayField for name (sorting) and a migration script, and let time tell if this is more useful than the current approach and wether it should become default or not after a long-enough while ?

Again, thanks for your reply, every time I read messages from engineers like you it makes me a better one myself and I'm sure it's the case for most other persons. I understand it can sometimes be hard for you - and other experienced core devs- to have to deal with us, so I really want to show my appreciation and love and I think I can speak for everyone of us when I say thank you for your contribution and your sharing and making everyone of us better every time you take some time for us.

Keep up the great work

Best regards

[Lee Trout]

I know there's always resistance to adding more settings but this seems like a candidate for a value in a setting with a sane default that a user could quickly and easily change. 

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALC3KaeNyMhAeG0_4L_j0KDg5hV_eAzucy42G1xiLMmfyHOtVQ%40mail.gmail.com.

[Malcolm Box]

A setting seems like a dangerous option here, since changing it would cause a DB migration to be required.

It's not *that* hard for us to find a value and apply it. Any user that really wanted something different could create their own migration to change the default - but "leave it to the user" still means picking a value for the sane default...

Cheers,

Malcolm

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAABi-DoVpZoTCKL9Mw-J%3DrSJhHFR1jo-WCr9gTVAa%2BBKWbsCjQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Malcolm Box

[Lee Trout]

I thought about that before I posted. I can't remember seeing any settings that would also carry db consequences other than adding an app. (Or the db setting dict itself).

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAF3R4sVikNLgr1DVtKw_3ps7gFuHrZbO3K1Zhv14ZuUzM5zR0A%40mail.gmail.com.

[Malcolm Box]

I've opened ticket 26993 to track this - https://code.djangoproject.com/ticket/26993#ticket

[Aymeric Augustin]

On 02 Aug 2016, at 14:23, James Pic <jame...@gmail.com> wrote:

> I understand it can sometimes be hard for you

Indeed, some aspects of this discussion frustrate me and that showed in my answer. Please accept my apologies for the unwarranted aggressiveness.

On an intellectual level, I understand why it’s more important for open-source software to give room to all opinions than to get to a solution as fast as possible, but I’m finding it hard to accept this process when it comes to changes I care about and that should have been done years ago. I’m still working on it!

--
Aymeric.

[Shai Berger]

Well, there's one precedent that is quite pertinent here, and that is AUTH_USER_MODEL. But a setting for the length of a field in a built-in app is problematic because it would imply a migration in that app, rather than user apps.

In principle we could write the d.c.auth migration by hand to take the setting in account, and declare the setting as unchangeable like AUTH_USER_MODEL, but that would be very ugly special-casing IMO.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Michal Petrucha]

On Tue, Aug 02, 2016 at 06:09:00PM +0300, Shai Berger wrote:
> Well, there's one precedent that is quite pertinent here, and that
> is AUTH_USER_MODEL. But a setting for the length of a field in a
> built-in app is problematic because it would imply a migration in
> that app, rather than user apps.
>
> In principle we could write the d.c.auth migration by hand to take
> the setting in account, and declare the setting as unchangeable like
> AUTH_USER_MODEL, but that would be very ugly special-casing IMO.

That would be very error prone, unless we wrap in a thick layer of
safety checks. django-allauth already does something like that (where
a migration conditionally adds an operation depending on a setting)
and it has already come up a bunch of times in #django when people got
their database schema into an inconsistent state by changing that
setting.

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Thank you Malcolm!

Let's see if we can reach a consensus in a reasonable time.

_____________________________________________

Raony Guimarães Corrêa Do Carmo Lisboa Cardenas
PhD in Bioinformatics

email: raonygu...@gmail.com
skype/hangouts: raonyguimaraes
phone: +48 722 148 478

_____________________________________________

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20160802151714.GG5430%40koniiiik.org.

[René Fleschenberg]

Hi,

 

> Anyway, it seems that this issue is bound to die in a bikeshedding fest,

> so I’ll leave it there, with my apologies to Brazilian users who will

> remain unable to log into Django-based websites :-(

 

Please don't let this issue die because we cannot reach consensus between 60, 100, 192 and 255. That would be silly. Django deserves better.

 

My personal gut feeling is that I prefer something higher than 60 (because why not), but Aymeric has made valid arguments for 60: the practically very relevant example of Portugese / Brazilian names plus some margin. If 60 is a value that allows us to move this forward without making a core developer feel bad about the change, let's go with 60.

 

I'm +1 on any limit 60+ and -1 on keeping the current limit.

 

--

René Fleschenberg

[Tim Allen]

Our main database in my division contains about 150,000 users total - from across the world. Although the distribution is heavily weighted towards North America and Europe, we do have a fair amount of Asian schools, and one from Brazil. Many of these schools also have international students. I hope some insights on these data may prove valuable.

We currently have fields for first name (max length=50), last name (max length=50), and full name (max length=100). These are in SQL Server (we are converting to PostgreSQL, one step at a time) and of type NVARCHAR, so that's inclusive of byte length for Unicode characters.

Even with our single Brazilian school, I can see the need for a last name field longer than 50 characters, and definitely longer than 30. We also have quite a few users who have chosen to populate their last name fields with input like 'Lastname (Sr John Huntsman Prof of Awesomeness)' in their last name field, where they've abbreviated due to the field length. Yes, that would be more appropriate for a title field, but I suspect we are not alone in having users exhibit / want this flexible behavior, so it appears everywhere their name does.

My two cents? Setting username, first_name, and last_name in Django to a max_length of ~192 would cover the most users, be backwards compatible even with MySQL < 5.0.3, and give a lot of flexibility to the developer. It is quite possible I've missed something, but figured I'd throw some observations based on our users out there. Thanks for the discussion.

Regards,

Tim

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Hi,

Now that this thread went silent for a few days, can we reach a consensus and try increase last_name to the maximum size available without breaking backward compatibility ?

Please, lets make Django more available to the rest of the world. This is a small change with a huge benefit to users.

Kind Regards

[Tom Christie]

I'd always defer towards humanized limits, rather than technical limits, so I'd suggest 100 chars seems like a decent cap.

[Aymeric Augustin]

> On 10 Aug 2016, at 17:34, Tom Christie <christ...@gmail.com> wrote:
>
> I'd always defer towards humanized limits, rather than technical limits, so I'd suggest 100 chars seems like a decent cap.

Yes.

Repeating my earlier message:

> I’m -1 on basing the decision of “how long a last name does Django allow by default” on an unrelated technical limit.


A humanised limit is more consistent with how Django handles limits historically. It avoids debating MySQL’s limits in various circumstances and thinking how the decision might affect databases supported via third-party backends.

100 will do.

--
Aymeric.

[Raony Guimaraes Corrêa Do Carmo Lisboa Cardenas]

Ok.

I agree we can set for an increase to 100 characters :) 

Cheers

_____________________________________________

Raony Guimarães Corrêa Do Carmo Lisboa Cardenas
PhD in Bioinformatics

email: raonygu...@gmail.com
skype/hangouts: raonyguimaraes
phone: +48 722 148 478

_____________________________________________

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/h98-oEi7z7g/unsubscribe.

To unsubscribe from this group and all its topics, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8076F842-B9A7-4772-83B7-80ADC93AAB7C%40polytechnique.org.

[Florian Apolloner]

On Wednesday, August 10, 2016 at 5:34:44 PM UTC+2, Tom Christie wrote:

I'd always defer towards humanized limits, rather than technical limits, so I'd suggest 100 chars seems like a decent cap.

Not trying to troll or derail, but can we please make it 150 chars? It is still kinda "humanized" and at least consistent with what we already have for the username. Having a different somewhat arbitrary field for every charfield on the usermodel strikes me as somewhat suboptimal.

Cheers,
Florian

[Alex Hill]

FWIW I agree with Florian:

• Where the default is unsuitable for a project, it's easier to restrict the field's length in forms than to increase it in the User model.
  
• It's hard to imagine a situation where a 100-character limit is suitable but a 150-character limit isn't.
• I can imagine myself as a new user wasting cycles wondering what the reason behind the different field lengths is, so I imagine others might too.

Cheers,

Alex