fix(query): client-side ORDER BY for PartiQL SELECTs

[fuleinist]

Summary

Two related fixes for PartiQL SELECT ordering/limiting in the Tabularis GUI:

1. Client-side ORDER BY — ORDER BY clauses in PartiQL SELECT statements no longer fail with ValidationException: Must have WHERE clause in the statement when using ORDER BY clause. DynamoDB's ExecuteStatement only accepts ORDER BY when a WHERE pins the partition key and the ordered column is the sort key — so any other form (sorting a table without a sort key, or ordering by a non-key column, exactly what the GUI emits when a column header is clicked) was rejected outright. The clause is now detected, stripped from the statement (after LIMIT stripping, so ORDER BY ... LIMIT n chains cleanly), and re-applied client-side over a bounded paged read of the result set. Numeric columns (DynamoDB N attributes serialised as JSON strings) sort numerically, not lexically; null/missing values sink to the end on ascending order. A 1000-row cap keeps the client-side sort bounded, with a warning returned when the cap is hit explaining how to get server-side ordering instead. A client-side sort is one-shot (no next_token), so the GUI re-issues the full statement to advance.

2. Unwrap GUI derived-table wrapper (fix(query): client-side ORDER BY for PartiQL SELECTs #66 follow-up) — filtered browses with a LIMIT no longer fail with ValidationException: Statement wasn't well formed, can't be processed: Expected RIGHT_PAREN. The GUI wraps such browses in a derived table — SELECT * FROM (<base> <where> <order_by> <limit>) AS limited_subset — which DynamoDB PartiQL does not support. The wrapper is now unwrapped before the LIMIT/ORDER BY strippers run, so they operate on the inner statement instead of slicing into the subquery and dropping its closing paren. A wrapper is only unwrapped when it is a single derived table with nothing else at the top level (a following JOIN or outer WHERE is left untouched). Parens are balanced with single-quoted string literals respected, so function calls and parens inside string values in the inner WHERE don't fool the balancer.

Root cause (reproduced against DynamoDB Local)

Client-side ORDER BY

Query	Before	After
SELECT * FROM "users" ORDER BY "age"	ValidationException: Must have WHERE clause...	sorted ascending (Bob 25, Alice 30, Carol 40)
SELECT * FROM "users" ORDER BY "age" DESC	same error	sorted descending (Carol, Alice, Bob)
SELECT * FROM "users" ORDER BY "age" DESC LIMIT 2	same error	top 2 by age desc, truncated=true
SELECT * FROM "events" WHERE "pk" = 'p1' ORDER BY "ts" DESC	already worked (server-side)	still correct (now client-side)
SELECT * FROM "users" LIMIT 2	already worked	unchanged

Derived-table unwrap

Query (exact GUI form)	Before	After
SELECT * FROM (SELECT * FROM "production-venue" WHERE id > 5 ORDER BY created_at DESC LIMIT 10) AS limited_subset	ValidationException: ... Expected RIGHT_PAREN	5 rows, sorted by created_at desc, limited to 10
SELECT * FROM (SELECT * FROM "production-venue" WHERE status = 'active' ORDER BY created_at DESC LIMIT 10) AS limited_subset	same error	3 active rows, sorted desc
SELECT * FROM (SELECT * FROM "a") AS x JOIN "b" ON x.id = b.id	n/a (not a pure wrapper)	left untouched (not unwrapped)

LIMIT alone was never broken — strip_partiql_limit has handled it since #34. ORDER BY never had any interception in the plugin (verified via git log -S "order_by" -- src), so it never actually "worked before"; what changed in v0.1.0-era was that real DynamoDB error messages started surfacing (commit 92d615e), making the previously opaque "service error" visible as the actionable ValidationException. The Expected RIGHT_PAREN regression appeared once the ORDER BY stripper was in place, because it found the ORDER BY inside the GUI's subquery wrapper and sliced off the closing paren.

Test plan

• cargo test --lib — 178 passed (13 ORDER BY/sort + 8 derived-table-unwrap unit tests)
• DYNAMODB_ENDPOINT=http://localhost:8000 cargo test --test dynamodb_local_test -- --test-threads=1 — 12 passed
• cargo clippy --all-targets -- -D warnings — clean
• cargo fmt --all — applied
• Manual reproduction against DynamoDB Local for all rows in both tables above
• End-to-end in Tabularis GUI: WHERE id > 5 + ORDER BY created_at DESC + LIMIT 10 returns sorted, limited rows (no error)

Notes

• Bumps version to 0.1.6 (Cargo.toml, Cargo.lock, .tabularium) and adds a CHANGELOG entry covering both fixes.
• The 1000-row client-side cap matches Client::MAX_SCAN_ITEMS; beyond it the sort is partial and a warning is returned. Server-side ordering remains available to users who write the supported form (WHERE pk = ? ORDER BY sk).
• unwrap_derived_table is conservative: it only fires on SELECT ... FROM (<inner>) [AS <alias>] with a single derived table and nothing else at top level. A JOIN or outer WHERE after the wrapper is left untouched (and would surface a clear DynamoDB parse error rather than a mangled statement).

Made with Cursor