Fix Appending ORDER BY Clauses

[Lightning11wins]

This PR will fix osrc widgets appending ORDER BY clauses to queries that already have an ORDER BY clause.

This is most commonly seen a table uses an osrc with a query that contains an ORDER BY clause. When the user clicks a column in the table header row to sort by that column, the user's new order is appended to the query and subsequently ignored by the parser, which only parses the first clause.

[greptile-apps]

Greptile Summary

This PR fixes a long-standing bug where clicking a table column header to sort would append a second ORDER BY clause to a query that already contained one, causing the user's chosen sort to be silently ignored by Centrallix's SQL parser. The fix introduces a proper SQL tokeniser (osrc_replace_orderby) that splices the new ORDER BY in place of any existing one, and also cleans up the sort-key construction in the table widget.

• osrc_replace_orderby (htdrv_osrc.js): New tokenising function using a single regex pass that correctly tracks single-quoted strings, -- and /* */ comments, and parenthesis depth, then replaces the last top-level ORDER BY range or inserts one before any trailing LIMIT/FOR/WITH/CROSSTAB clause.
• Two call sites updated: Both osrc_query_text_handler and osrc_query_object_handler now call osrc_replace_orderby instead of unconditionally appending, removing ~30 lines of duplicated loop logic.
• tbld_mousedown (htdrv_table.js): Sort-key construction factored into sort_key/sort_asc/sort_desc constants; comparison operators tightened to ===; colon-prefixed column names (e.g. :t:a_field) now pass through verbatim instead of being double-wrapped in quotes.

Confidence Score: 5/5

Safe to merge; the tokeniser correctly handles all SQL noise tokens and the two call-site replacements are straightforward.

The core tokenising logic is well-constructed: quoted strings, both comment styles, and nested parentheses are all skipped before keywords are inspected. The only notable edge case — empty orderby_items removing an existing ORDER BY — is unlikely to be triggered by any current call path.

No files require special attention.

Important Files Changed

Filename	Overview
centrallix-os/sys/js/htdrv_osrc.js	Adds osrc_replace_orderby, which correctly tokenises SQL (handling single-quoted strings, -- and /* */ comments, and nested parens) to splice a new ORDER BY in place of any existing one; replaces the two old naïve-append blocks with single calls to this helper. Minor edge case: empty orderby_items silently strips an existing ORDER BY.
centrallix-os/sys/js/htdrv_table.js	Refactors header-click sort logic: extracts sort_key/sort_asc/sort_desc constants, switches to strict equality (===), and adds verbatim pass-through for colon-prefixed column names (e.g. :t:a_field). No logic regressions observed.

_{Reviews (2): Last reviewed commit: "Update table ORDER BY generation to supp..." | Re-trigger Greptile}

[Lightning11wins]

This PR is ready for human review.

[gbeeley]

I'd like to zig here instead of zagging. Having the JS code splice code into an existing ORDER BY clause seems prone to issues. Instead, I'd like to update the SQL parser to allow multiple ORDER BY clauses in the same way that it allows multiple WHERE and HAVING clauses for the exact same reason. This should be doable by replacing some IF blocks with WHILE blocks where ORDER BY items are collected in a few places and by updating mq_internal_PostProcess() to look for multiple ORDER BY clauses.

We will need a small SQL syntax change, adding a DEFAULT keyword to optionally follow ORDER BY, thus indicating that the ORDER BY clause can be overridden by another ORDER BY instead of just added to. That clarifies the SQL author's intent with the ORDER BY to be preset functionally vs providing a useful default ordering.

[gbeeley]

See note in conversation. I think there is a much better way to solve this problem.

[Lightning11wins]

I suppose I should have realized that this would turn into a rearchitecting problem instead of a patch-it-until-it-works problem and reached out to you sooner. I'll see if I can figure out how to implement that.

[Lightning11wins]

Question 1

Let me clarify. In the following SQL example:

SELECT *
FROM /path/to/object
ORDER BY
  :prop1,
  :prop2
ORDER BY DEFAULT
  :prop3
ORDER BY
  :prop4
ORDER BY DEFAULT
  :prop5

The final ordering would be by :prop4,:prop5, right?

[Lightning11wins]

Question 2

Are you sure DEFAULT is the best name for this? It doesn't seem like that's a standard thing in SQL, and it also feels coupled to this usecase. Maybe something like FINAL/OVERRIDEABLE or we could use something like EXTENDABLE to indicate the opposite?

I'll call it DEFAULT for now, but I thought it was worth checking that this is a good design decision for Centrallix SQL as a language.

[gbeeley]

I think the principles here should be:

• Any ORDER BY clause after an ORDER BY DEFAULT overrides that ORDER BY DEFAULT in its entirety.
• Otherwise, additional ORDER BY clauses just add to the ORDER BY criteria (i.e. provide finer-grained ordering).

So, the question above would end up being the same as ORDER BY :prop1, :prop2, :prop5.

The ordering in your edited version would be :prop1, :prop2, :prop4, :prop5. Prop4 would override prop3.

I'm open to alternate terminology on this vs DEFAULT. It's not a standard SQL feature to support multiple clauses like this, so we're in our own territory. But DEFAULT is already a SQL reserved word, whereas the others are not.

[Lightning11wins]

I just created #127 to implement this new feature, with tests and docs. That PR is ready for human review, closing this now-obsolete implementation.