Re: Google Summer of Code Updates - Class based indexes

[akki]

   - Add support for column ordering (ASC/DESC) in class based indexes
   Completed - tests, docs, code
   PR - https://github.com/django/django/pull/6982
   
   - Implement Hash index class
   Add capability to get type of index in introspection (required for 
   testing this feature)
   Completed - Add tests, docs, code
   PR - https://github.com/django/django/pull/6995
   Ticket - https://code.djangoproject.com/ticket/26974
   
   - Some minor changes in !6857 
   

Other than these, I also had a look at btree_gin indexes and extensions but 
haven't started the implementation yet.

On Wednesday, 27 July 2016 20:26:38 UTC+5:30, akki wrote:
>
> Hi Jani
>
> Thanks a lot for offering help. I did face some issues with the Oracle 
> setup in the beginning but was able to resolve them yesterday. :)
> You are most welcomed to review the PR and offer any suggestions for 
> improvement at https://github.com/django/django/pull/6982/. The work 
> related to the feature is in progress but the introspection-related work is 
> mostly complete.
>
> Regards
> Akshesh(akki)
>
> On Tuesday, 26 July 2016 16:47:32 UTC+5:30, Jani Tiainen wrote:
>>
>> Hi,
>>
>> On 26.07.2016 04:28, akki wrote:
>>
>>
>>
>>- Fixed #24442  - 
>>Improved schema's index name creating algorithm
>>Updated !6898  to take all 
>>column names into account while creating index name 
>>
>>
>>- Add support for column ordering (ASC/DESC) in class based indexes
>>Somewhat provides the feature requested in #20888 
>>
>>WIP code on my branch - 
>>https://github.com/akki/django/commits/gsoc-indexes-order
>>Modifying introspection of all databases to return column order as 
>>well (required for testing) -- implementation for Oracle remaining.
>>
>>
>> If you get stuck with Oracle I can lend a hand to help to figure out the 
>> details.
>>
>>
>>- Implement Hash index class
>>WIP implementation at 
>>https://github.com/akki/django/commits/gsoc-indexes-hash
>>Currently implemented only for postgresql because that's the only 
>>backend which fully supports it AFAIK (MySQL supports for some storage 
>>engines but neither for MyISAM nor InnoDB). 
>>
>>
>> On Tuesday, 19 July 2016 10:41:16 UTC+5:30, akki wrote: 
>>>
>>>
>>>- Introduce Meta.indexes
>>>PR - https://github.com/django/django/pull/6857.
>>>Ticket - https://code.djangoproject.com/ticket/26808.
>>>Made a design change so that index can drop it's model attribute by 
>>>introducing *Index.set_name_with_model* method
>>>Wrote some left out tests for *related_dependencies*.
>>>
>>>- Fixed #24442  - 
>>>Improve schema's index name creating algorithm
>>>PR  - https://github.com/django/django/pull/6898 
>>>
>>>Updated according to reviews and suggestions.
>>>
>>>- Resolved bug when unique_together was dropped along with it's field
>>>PR - https://github.com/django/django/pull/6926.
>>>Initially wrote a temporary fix (which left out some other corner 
>>>cases) to the problem (afterwards I realised the better fix and sent PR).
>>>Other comments about the issue on the ticket -  
>>>
>>>https://code.djangoproject.com/ticket/26180.
>>>Resolved a similar issue that had crept up for Meta.indexes - 
>>>updated !6857  
>>>accordingly.
>>>
>>>
>>> On Tuesday, 12 July 2016 14:17:21 UTC+5:30, akki wrote: 


- Restructure index migrations - Polished according to all reviews, 
the PR  has been merged. 
- Introduce Meta.indexes - Updated PR 
 according to 
suggestions as per reviews. 
- Improve schema's index name creating algorithm - #24442 
 !6898 
.
- Add support for indexes to inspectdb - This depends on !6857 
 so I will send a PR 
once indexes are added to Meta class; Current work on my local branch - 
  

https://github.com/akki/django/commits/gsoc-indexes-inspectdb 

 On Tuesday, 5 July 2016 11:54:00 UTC+5:30, akki wrote:

>
>- Restructure index migrations
>PR  - https://github.com/django/django/pull/6866
>Modified the internal working of migrations/schema methods related 
>to indexes. This mainly aims at stabilising the newly added migrations 
> fo

Re: Need help with MySQL 5.7 crashing on Django's Jenkins

[gilberto dos santos alves]

hi. please post your /etc/my.ini  (or your equiv. mysql ini config file).

2016-08-01 21:05 GMT-03:00 Tim Graham :

> Sometimes the MySQL 5.7.13 builds on Ubuntu 16.04 are failing with "Lost
> connection to MySQL server during query" because the MySQL server restarts
> during the tests. I wonder if anyone has an idea about how to solve this.
> Looking through the MySQL error log, I think this is the root cause:
>
> 2016-08-01T23:02:56.636617Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has
> lasted > 600 seconds. We intentionally crash the server because it appears
> to be hung.
> 2016-08-01 23:02:56 0x7f5fb75d8700  InnoDB: Assertion failure in thread
> 140049074980608 in file ut0ut.cc line 920
> InnoDB: We intentionally generate a memory trap.
> InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
> InnoDB: If you get repeated assertion failures or crashes, even
> InnoDB: immediately after the mysqld startup, there may be
> InnoDB: corruption in the InnoDB tablespace. Please refer to
> InnoDB:
> http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
> InnoDB: about forcing recovery.
> 23:02:56 UTC - mysqld got signal 6 ;
> This could be because you hit a bug. It is also possible that this binary
> or one of the libraries it was linked against is corrupt, improperly built,
> or misconfigured. This error can also be caused by malfunctioning hardware.
> Attempting to collect some information that could help diagnose the
> problem.
> As this is a crash and something is definitely wrong, the information
> collection process might fail.
>
> key_buffer_size=536870912
> read_buffer_size=131072
> max_used_connections=4
> max_threads=151
> thread_count=4
> connection_count=4
> It is possible that mysqld could use up to
> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
> 584285 K  bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
>
> Thread pointer: 0x0
> Attempting backtrace. You can use the following information to find out
> where mysqld died. If you see no messages after this, something went
> terribly wrong...
> stack_bottom = 0 thread_stack 0x20
> /usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe7bdab]
> /usr/sbin/mysqld(handle_fatal_signal+0x489)[0x783759]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x7f60131dc3d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f6012596418]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f601259801a]
> /usr/sbin/mysqld[0x759764]
> /usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0x145)[0x110c905]
> /usr/sbin/mysqld(srv_error_monitor_thread+0xe2d)[0x10aa34d]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f60131d26fa]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6012667b5d]
> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html
> contains
> information that should help you find out what is causing the crash.
>
> --
> 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-developers+unsubscr...@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/3f787f25-2e3f-49b1-b6a3-7a3411e70a9b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

-- 
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-developers+unsubscr...@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/CAP9G-NKdUmCcWUn0syVRtMRCwdKYgO%3DyXf13%3DfXgZABaBsW9MQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Django 1.10 and 1.9.9 released

[Josh Smeaton]

Awesome! Thanks Tim, once again, for driving the release process on time. 
Love your work!

On Tuesday, 2 August 2016 05:03:27 UTC+10, Tim Graham wrote:
>
> Django 1.10 and a bug fix release for the 1.9 series (1.9.9) are now 
> available:
>
> https://www.djangoproject.com/weblog/2016/aug/01/django-110-released/
>
> With the release of Django 1.10, Django 1.9 has reach end of mainstream 
> support. It will continue to receive security and data loss fixes for 
> another eight months until April 2017. See the downloads page [1] for a 
> table of supported versions and the future release schedule.
>
> [1] https://www.djangoproject.com/download/#supported-versions
>

-- 
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-developers+unsubscr...@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/ae54f852-6fe3-42d8-84fe-68e0c74dfc33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Need help with MySQL 5.7 crashing on Django's Jenkins

[Tim Graham]

Sometimes the MySQL 5.7.13 builds on Ubuntu 16.04 are failing with "Lost 
connection to MySQL server during query" because the MySQL server restarts 
during the tests. I wonder if anyone has an idea about how to solve this. 
Looking through the MySQL error log, I think this is the root cause:

2016-08-01T23:02:56.636617Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has 
lasted > 600 seconds. We intentionally crash the server because it appears 
to be hung.
2016-08-01 23:02:56 0x7f5fb75d8700  InnoDB: Assertion failure in thread 
140049074980608 in file ut0ut.cc line 920
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
23:02:56 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=536870912
read_buffer_size=131072
max_used_connections=4
max_threads=151
thread_count=4
connection_count=4
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 
584285 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x20
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xe7bdab]
/usr/sbin/mysqld(handle_fatal_signal+0x489)[0x783759]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x7f60131dc3d0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f6012596418]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f601259801a]
/usr/sbin/mysqld[0x759764]
/usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0x145)[0x110c905]
/usr/sbin/mysqld(srv_error_monitor_thread+0xe2d)[0x10aa34d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x7f60131d26fa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6012667b5d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

-- 
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-developers+unsubscr...@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/3f787f25-2e3f-49b1-b6a3-7a3411e70a9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django 1.10 and 1.9.9 released

[Tim Graham]

Django 1.10 and a bug fix release for the 1.9 series (1.9.9) are now 
available:

https://www.djangoproject.com/weblog/2016/aug/01/django-110-released/

With the release of Django 1.10, Django 1.9 has reach end of mainstream 
support. It will continue to receive security and data loss fixes for 
another eight months until April 2017. See the downloads page [1] for a 
table of supported versions and the future release schedule.

[1] https://www.djangoproject.com/download/#supported-versions

-- 
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-developers+unsubscr...@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/5a160292-1f43-410f-acc4-c136d8badafe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[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: raonyguimar...@gmail.com
skype/hangouts: raonyguimaraes
phone: +48 722 148 478
_

On Mon, Aug 1, 2016 at 3:45 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello James,
>
> > On 01 Aug 2016, at 15:03, James Pic  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,% 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,% of a problem with a very
> small effort like I suggested is a practical approach.
>
>
> --
> Aymeric
>
> --
> 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+unsubscr...@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/ED879BC4-F89D-48D6-9B09-2778FBDBF998%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this gr

Re: Extend support for long surnames in Django Auth

[Aymeric Augustin]

Hello James,

> On 01 Aug 2016, at 15:03, James Pic  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,% 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,% of a problem with a very 
small effort like I suggested is a practical approach.


-- 
Aymeric

-- 
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-developers+unsubscr...@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/ED879BC4-F89D-48D6-9B09-2778FBDBF998%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[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

On Mon, Aug 1, 2016 at 9:03 AM James Pic  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. So I'm a bit lost about
> what's the most practical approach here.
>
> --
> 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-developers+unsubscr...@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/CALC3KaeTBeRU-S2Kk_639ikFP7Z7rxc7LAV17qcDfHM63ATh%3Dw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-developers+unsubscr...@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/CAGdCwBt%2BNtLH5OgMcCSpwbdVnQ0qU02UaRK_yWo8KhCA4QReog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[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.

-- 
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-developers+unsubscr...@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/CALC3KaeTBeRU-S2Kk_639ikFP7Z7rxc7LAV17qcDfHM63ATh%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Aymeric Augustin]

> On 30 Jul 2016, at 23:15, Donald Stufft  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.

-- 
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-developers+unsubscr...@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/710CA663-E7A6-405B-AC53-DE32A7FB1F12%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.