mirror of
https://github.com/supabase/supabase.git
synced 2026-09-06 09:59:03 +08:00
0ed49231b7
Third of a stack. **Stacked on #49070** (which is stacked on #49069) — review those first. Base retargets automatically as each merges. Mechanical throughout; no behavior change. ## The problem Three types described where a query runs, and no two agreed: | | shape | |---|---| | `CellSource` (registry) | `{ id, type, parameters: { … } }` — `id` and `type` always held the same literal | | `QuerySource` (SQL editor) | `{ type: 'database' } \| { type: 'logs', dateRange }` | | notebook cells | flat per-backend fields, neither of the above | Anything crossing between them needed a translation that dropped fields on the way — which is how a notebook cell's replica selection had nowhere to go. ## What changed One `QuerySourceBinding`: a backend `_tag` with that backend's parameters spread flat beside it, borrowed from the wire schema (#49069) so the binding and the persisted cell agree by construction. - **`QuerySource` is deleted.** `useRunSource` returns the shared binding, so `runSource.type`/`dateRange` become `_tag`/`time_range` across the SQL editor — that is most of the file count here. - **`getQuerySourceBinding`** projects a notebook cell onto a binding; **`toQuerySourceBinding`** does the same for any backend-tagged carrier. Both overloaded so an already-narrowed caller gets the matching binding back rather than the union, which keeps the result spreadable without re-narrowing. - **`ExplorerQuerySourceMenu`** drops its inline copy of the custom-range and upgrade-prompt logic in favor of `useLogsCustomRange`, which the SQL editor menu already used. The registry keeps only what is genuinely runtime: endpoints, labels, icons, availability, defaults. What a query *is* stays in the wire schema. ## Verification Typecheck, Prettier, and the lint ratchet clean. 405 tests pass across the notebook schema, query sources, the logs components, the SQL editor, and the Explorer surfaces. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * Updated query source handling across Explorer and SQL Editor for a more consistent selection experience. * Database and log sources now preserve identifiers and time ranges more reliably when switching or editing queries. * Source menus, labels, icons, validation, and query execution now reflect the selected source more accurately. * **Bug Fixes** * Invalid or outdated saved source settings now safely fall back to a database source. * Improved log-source detection and time-range handling throughout query editing and execution. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
57 lines
2.3 KiB
TypeScript
57 lines
2.3 KiB
TypeScript
import type { Snippet } from '@/data/content/sql-folders-query'
|
|
import { type QuerySourceTag } from '@/data/query-sources/query-source-registry'
|
|
|
|
/**
|
|
* Domain view of where a snippet's query runs. Derived from the content TYPE:
|
|
* a `log_sql` snippet always targets the logs backend and a `sql` (or `report`)
|
|
* snippet always targets the user's Postgres database. A snippet's source is
|
|
* immutable — switching backends means creating a new snippet, not toggling this
|
|
* value.
|
|
*/
|
|
export type SqlSnippetSource = QuerySourceTag
|
|
|
|
/**
|
|
* The single reader every surface (AI, reports, tabs, nav, execution) uses to
|
|
* decide where a snippet runs. `'log_sql'` → `'logs'`; everything else (`'sql'`,
|
|
* `'report'`) → `'database'`. Accepts the raw `Snippet['type']` so a snippet of
|
|
* any content type maps to a source without narrowing first.
|
|
*/
|
|
export function getSnippetSource(snippet: Pick<Snippet, 'type'>): SqlSnippetSource {
|
|
return snippet.type === 'log_sql' ? 'logs' : 'database'
|
|
}
|
|
|
|
export function isLogsSource(source: SqlSnippetSource | undefined): boolean {
|
|
return source === 'logs'
|
|
}
|
|
|
|
/**
|
|
* The markdown fence language a source's SQL is written into a prompt with, so the model
|
|
* can tell a ClickHouse logs query from Postgres SQL. */
|
|
export function sqlSourceToFenceLanguage(
|
|
source: SqlSnippetSource | undefined
|
|
): 'sql' | 'clickhouse' {
|
|
return isLogsSource(source) ? 'clickhouse' : 'sql'
|
|
}
|
|
|
|
/**
|
|
* Parse a raw `source` value (e.g. the `?source=` query param a creation entry
|
|
* threads through `/sql/new`) into a `SqlSnippetSource`. Only the explicit
|
|
* `'logs'` opts a new snippet into the logs backend; anything else — including an
|
|
* absent param — is a database snippet, keeping database the safe default.
|
|
*/
|
|
export function parseSqlSnippetSource(raw: string | undefined): SqlSnippetSource {
|
|
return raw === 'logs' ? 'logs' : 'database'
|
|
}
|
|
|
|
/**
|
|
* Resolve where an open snippet's query runs, falling back to the `?source=` URL param
|
|
* when the snippet isn't in the store yet — a fresh `/sql/new` tab is materialized
|
|
* lazily on the first keystroke, and until then the param is the only signal.
|
|
*/
|
|
export function resolveSnippetSource(
|
|
snippet: Pick<Snippet, 'type'> | undefined,
|
|
sourceParam: string | undefined
|
|
): SqlSnippetSource {
|
|
return snippet !== undefined ? getSnippetSource(snippet) : parseSqlSnippetSource(sourceParam)
|
|
}
|