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
On 01/08/16 09:34, James Pic wrote:
On Sat, Jul 30, 2016 at 8:08 AM, Josh Smeaton <josh.smea...@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)
--
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/c4e945a3-61bd-3917-dec5-9758b0d2790e%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.
