Altinity / Altinity/altinity-sql-browser

[sup] Parameters: forward natively server-side, else strict {name:Type} renderer + parity test

Open
#355 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement sup
Dominant language
TypeScript
Stars
8
Forks
2
Avg merge
1h 34m
Merged PRs (30d)
6

Description

Part of #352. Native param_* are not forwarded by the proxy (verified UNKNOWN_QUERY_PARAMETER).

Preferred: forward params server-side (ACM-side ask)

Given tight ACM integration is a plus, the cleanest fix is to have /api/cluster/{id}/query accept a structured param map (and settings) and bind them natively in ClickHouse — no client-side SQL rewriting, full type parity. Raise with the ACM team first; if accepted, this issue reduces to wiring runQuery's params through the request body.

Fallback: strict client-side {name:Type} renderer

If native forwarding isn't available, render typed value placeholders {name:Type} (CH syntax) → SQL literals, typed values only, no free-form/identifier macros. Do not reuse core/param-serialize.ts (it targets the HTTP param_* channel: passes scalar strings raw, treats unknown types as opaque — not inline-SQL-safe or type-equivalent). Instead a separate strict renderTypedSqlExpression:

  1. explicit allowlist of supported type ASTs (reject unknown);
  2. parse compound values into structured values (never trust free-form strings);
  3. quote every textual component; emit explicit casts where CH semantics need them (e.g. {x:UUID}CAST('…' AS UUID), Date/DateTime64/Decimal/Enum/IPv4/6/large-int);
  4. reuse the existing occurrence scanner's exact spans (ignores placeholders in literals/comments); replace right-to-left.

Acceptance

  • Decision recorded: native forwarding vs. client renderer.
  • If renderer: allowlisted types render + CAST where needed; unsupported values fail closed.
  • Parity test: same query+values via native param_* (public build) vs. this path → identical results, types, and toTypeName().

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with runQuery and the /api/cluster/{id}/query request path, then review core/param-serialize.ts and the existing occurrence scanner. First record whether native forwarding is available; if not, implement the specified strict renderer and verify the acceptance checklist, including parity of results, types, and toTypeName() against native param_* behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql, typescript
Domain
backend-api-design, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.