django
Ordering of Individual Members is unexpected
On the Individual Members page and in the Django admin, the sorting of the names seems to ignore spaces. This leads to surprising results when people share a first name (or close), for example:
- Tim Allen
- Tim Baxter
- Tim Graham
- Tim Kamanin
- Timo Zimmermann
- Tim Schilling
I would have expected Timo to either be at the start or (most likely) end of that list, not in the middle.
Investigating with @ontowhee, we suspect it’s a matter of how collation is set up (the SQL for the ordering is just ORDER BY "members_individualmember"."name" ASC). Not sure if we want to change the collation on the field with db_collation, or for this specific query.
This might not be a bug. There is a similar question posted on stackexchange and a good explanation about how unicode uses weights in its sorting algorithm. This allows names with non-ascii letters to be among those with only ascii letters.
I can't reproduce this locally, but we could add |dictsort:"name" to the for loop in the template to re-sort the values in Python. That should provide the desired behavior.
I personally don't think it's worth changing the database's collation for this. So my suggestion is to either close it or use dictsort. I'm curious what others think!
I'd like to see what collation is currently in use in production for that table/column. My presumption is that it is different from what is considered common by today's standards - given Adam was not able to reproduce this locally. Maybe we want to do something about that, align developer and production environments more.
Worth the effort? Might be; Otherwise adding the dictsort template filter sounds reasonable enough to me.
@Stormheg That sounds reasonable. Could someone from ops check that for us? Maybe @bmispelon or @tobiasmcnulty? The model is members.models.IndividualMember, and the table for me locally is members_individualmember.
djangoproject=> \l
List of databases
Name | Owner | Encoding | Locale Provider | Collate | Ctype | Locale | ICU Rules | Access privileges
--------------------------------+--------------------+----------+-----------------+-------------+-------------+--------+-----------+-----------------------
<snip>
djangoproject | djangoproject | UTF8 | libc | en_US.UTF-8 | en_US.UTF-8 | | |
<snip>
djangoproject=> \d members_individualmember
Table "public.members_individualmember"
Column | Type | Collation | Nullable | Default
--------------------+------------------------+-----------+----------+-----------------------------------------------------
id | integer | | not null | nextval('members_developermember_id_seq'::regclass)
name | character varying(250) | | not null |
email | character varying(254) | | not null |
member_since | date | | not null |
member_until | date | | |
reason_for_leaving | text | | not null |
Indexes:
"members_developermember_pkey" PRIMARY KEY, btree (id)
"members_developermember_email_4ac3d0fd6ffd575a_like" btree (email varchar_pattern_ops)
"members_developermember_email_key" UNIQUE CONSTRAINT, btree (email)
Referenced by:
TABLE "members_team_members" CONSTRAINT "mem_individualmember_id_3f05fb2b_fk_members_individualmember_id" FOREIGN KEY (individualmember_id) REFERENCES members_individualmember(id) DEFERRABLE INITIALLY DEFERRED
Please feel free to close this if it’s a can of worms. It makes it a teeny tiny harder to find who is a member when going through the list, not too bad, assuming we won’t double the amount of Tims in the near future 👁️
Ok thanks!
@Stormheg Are you ok with me closing this, or do you want to keep investigating it?
I think it is still a nice albeit tiny improvement.
Feel free to close or fix it 👍
@Stormheg Ok, I'll close it. Please reopen it if you have an idea for a fix!