🐛 When sorting Pools by Publishing Date, null dates should appear at bottom when sorting descending

[tristan-orourke]

🐛 Bug

Currently, when you sort Pools by Publishing Date descending, unpublished pools appear at the top, THEN recently published pools, THEN pools published a long time ago. This isn't very useful, since when sorting by published, I'm likely to want to know which ones were published most recently. All the unpublished pools get in the way of finding those.

🦋 Expected Behaviour

Unpublished pools (NULL date) should appear at the end of the list when sorting by publish date descending.

QUESTION: should NULLs always appear at the end of the list, whether sorting by ascending or descending?

🕵️ Details

📋 Steps to Reproduce

1. Log in as admin
2. go to pools table
3. Sort by publish date
4. Observe that you have to pass all the unpublished pools before getting to recently published pools

📸 Screenshot

🙋‍♀️ Proposed Solution

✅ Acceptance Criteria

• [ ] When sorting pools by publish_date descending, null dates appear at end of the list
• [ ] QUESTION: maybe? When sorting pools by publish_date descending, null dates still appear at end of the list

[esizer]

Just a heads up on this one since I ran into it previously. This is determined at the database level and we don't have much control over it at the graphql level so it might be tricky since lighthouse-php doesn't expose this level of control.

The default behavior in postrgres is to treat null as larger than all other values so will always appear at the top of the list when sorting descending unless specified otherwise.

[vd1992]

@esizer

Do you have any ideas for how to approach this? Table sort would also be out of the question as internal sort is false for all server-driven tables.

[petertgiles]

Yeah, I'm not sure where to go with this one either. When writing raw SQL it's easy enough to add a NULLS LAST option but since we're using the lighthouse @orderBy directive we don't have that level of control. I guess we could write a custom scope for the ordering? That seems pretty like a heavy-handed solution to a fairly minor annoyance though. I think the @orderBy also prevents us from sorting on a calculated column.