Sort every view newest first - #288
Merged
Merged
Conversation
"Alles" and "Te controleren" looked like they showed recent work. They showed whatever the API's fallback ordering produced, which is coalesce(update_date, create_date) DESC -- and the #973 backfill stamped one identical update_date onto 20,950 of 26,671 inquiries, so four rows in five sat in a single tie group in an order nobody chose. The explorer now always sorts. sort is no longer nullable: the query starts at document_date DESC, every request carries it, and the fallback is simply unreachable. Newest first on the one date the table shows, so the claim can be checked by reading down the Datum column rather than taken on trust. The Werkbank lanes get it too, where it shows more: a lane previews the first eight of the fifty it fetches, so an unsorted fetch meant eight arbitrary rows out of that same tie group. Falling out of "there is no unsorted state": the sort chip appears only once you deviate from the default (a chip on every screen is furniture, and its cross would do nothing), clicking a column twice flips direction instead of switching sorting off, and views saved before today -- which live in localStorage with sort: null -- are read back onto the default rather than resurrecting the old behaviour. Paging over this is only total once FunderMapsApi #101 lands the primary key as the last ORDER BY key. Until then document_date narrows the ties from one group of 20,950 to groups of about three, which is strictly better than what shipped before it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Answers "can the predefined filters show the newest items?" — and the answer turned out to be that they weren't showing anything in particular.
What was actually happening
Leaving
sortoff letGET /inquiryfall back tocoalesce(update_date, create_date) DESC. That sounds like recency. It isn't:20,950 of 26,671 inquiries share one timestamp, so four rows in five sat in a single tie group, in an order nobody chose and
LIMIT/OFFSETdoes not promise to keep stable between two pages. "Alles" only looked sorted.The change
sortis no longer nullable. The explorer starts atdocument_date DESC, every request carries it, and the endpoint's fallback becomes unreachable. Newest first on the one date the table actually shows — so "newest first" is checkable by reading down the Datum column instead of taken on trust. (Sorting onidwould be newest-entered, but would make the visible date column look shuffled.)The Werkbank lanes get it too, where it mattered more: a lane previews the first 8 of the 50 it fetches, so an unsorted fetch meant eight arbitrary rows out of that tie group.
Consequences of there being no unsorted state any more:
×would be a button that does nothing.localStorageholdingsort: null.fromViewreads anything unrecognised back onto the default, so an old saved view can't resurrect the old behaviour.Ordering note
Paging over this is only total once FunderMapsApi #101 adds the primary key as the last
ORDER BYkey. Until that merges,document_datenarrows the ties from one group of 20,950 to groups of roughly three — strictly better than what's on prod now, and independent of it, so this can ship first.Verification
vue-tsc+ eslint clean,pnpm buildgreen, plus two throwaway harnesses (deleted before commit):document_date descand reach the API that way; the default stays out of the URL while a deviation carries both halves;?sort=absent or nonsense lands on the default; a legacysort: nullsaved view is migrated on read; chip appears/clears correctly; every column still round-trips.🤖 Generated with Claude Code