@rebasepro/server 0.15.0 → 0.16.0

package/dist/src-CrCxd8km.js.map

@@ -1 +1 @@
-{"version":3,"file":"src-CrCxd8km.js","names":[],"sources":["../../types/src/types/filter-operators.ts","../../types/src/types/data_source.ts","../../types/src/types/collections.ts","../../types/src/types/rls-functions.ts"],"sourcesContent":["/**\n * Canonical filter operators and REST wire-format mappings.\n *\n * `WhereFilterOp` is THE operator type used at every layer — from React\n * components through the SDK, server, and down to the database driver.\n *\n * PostgREST short-codes (`eq`, `gt`, `cs`, …) exist **only** at the\n * HTTP wire boundary, handled by `serializeFilter` / `deserializeFilter`\n * in `@rebasepro/common`.\n *\n * ┌──────────────────────┬───────────────┬──────────────────────────────┐\n * │ Canonical            │ REST short    │ Meaning                      │\n * ├──────────────────────┼───────────────┼──────────────────────────────┤\n * │ \"==\"                 │ \"eq\"          │ Equal                        │\n * │ \"!=\"                 │ \"neq\"         │ Not equal                    │\n * │ \">\"                  │ \"gt\"          │ Greater than                 │\n * │ \">=\"                 │ \"gte\"         │ Greater than or equal        │\n * │ \"<\"                  │ \"lt\"          │ Less than                    │\n * │ \"<=\"                 │ \"lte\"         │ Less than or equal           │\n * │ \"in\"                 │ \"in\"          │ Value in list                │\n * │ \"not-in\"             │ \"nin\"         │ Value not in list            │\n * │ \"array-contains\"     │ \"cs\"          │ Array contains element       │\n * │ \"array-contains-any\" │ \"csa\"         │ Array contains any of        │\n * │ \"like\"               │ \"like\"        │ SQL LIKE (case-sensitive)    │\n * │ \"ilike\"              │ \"ilike\"       │ SQL ILIKE (case-insensitive) │\n * │ \"not-like\"           │ \"nlike\"       │ NOT LIKE (case-sensitive)    │\n * │ \"not-ilike\"          │ \"nilike\"      │ NOT ILIKE (case-insensitive) │\n * │ \"is-null\"            │ \"isnull\"      │ Field IS NULL                │\n * │ \"is-not-null\"        │ \"notnull\"     │ Field IS NOT NULL            │\n * └──────────────────────┴───────────────┴──────────────────────────────┘\n *\n * Pattern matching (`like`/`ilike`) uses SQL wildcard syntax: `%` matches any\n * sequence of characters, `_` matches a single character. On MongoDB these are\n * translated to anchored regular expressions; Firestore has no native pattern\n * matching and rejects these operators (use `searchString` instead).\n *\n * @module\n */\n\n/**\n * Canonical sort representation: `[fieldName, direction]`.\n *\n * Used in `FindParams.orderBy`, `collection.sort`, and `FilterPreset.sort`.\n * The colon-string form (`\"field:direction\"`) exists only at the HTTP wire\n * boundary, handled by `serializeOrderBy` / `deserializeOrderBy` in\n * `@rebasepro/common`.\n *\n * @group Models\n */\nexport type OrderByTuple<Key extends string = string> = [Key, \"asc\" | \"desc\"];\n\n/**\n * One sort key, or several applied in order of significance.\n *\n * ```ts\n * orderBy: [\"created_at\", \"desc\"]                      // one key\n * orderBy: [[\"roles\", \"asc\"], [\"created_at\", \"desc\"]]  // roles, then newest first\n * ```\n *\n * The two forms are told apart by whether the first element is itself an\n * array, so a single tuple never needs wrapping and every existing caller\n * keeps working unchanged. `normalizeOrderBy` in `@rebasepro/common` collapses\n * both to the list form, which is what every layer below the call site speaks.\n *\n * Ties on the last key are broken by the row id, so a multi-key sort is a\n * total order and pages over it neither repeat nor skip rows.\n *\n * @group Models\n */\nexport type OrderBySpec<Key extends string = string> =\n    | OrderBySortTuple<Key>\n    | OrderBySortTuple<Key>[];\n\n/**\n * A sort key: a field name, or an aggregate over a to-many relation.\n *\n * @group Models\n */\nexport type SortKey<Key extends string = string> = Key | RelationAggregateSort;\n\n/**\n * `[sortKey, direction]` — the authoring form of {@link OrderByTuple}, which\n * additionally accepts a {@link RelationAggregateSort} object.\n *\n * The object never reaches a driver: `normalizeOrderBy` in `@rebasepro/common`\n * encodes it to its string spelling on the way down, and everything below that\n * point speaks plain `OrderByTuple`. See {@link RelationAggregateSort} for why\n * the wire form is a string.\n *\n * @group Models\n */\nexport type OrderBySortTuple<Key extends string = string> = [SortKey<Key>, \"asc\" | \"desc\"];\n\n/**\n * The aggregate functions a relation sort can apply.\n *\n * Five, and no `array_agg`/`string_agg`: an aggregate used as a sort key has to\n * produce something with an order, and these are the ones that do.\n *\n * @group Models\n */\nexport type RelationAggregateFn = \"min\" | \"max\" | \"count\" | \"sum\" | \"avg\";\n\n/**\n * Order rows by an aggregate over the rows a to-many relation reaches —\n * \"candidates, oldest waiting first\", \"clients, busiest first\".\n *\n * ```ts\n * // The date of each candidate's earliest open application.\n * orderBy: [[{ relation: \"applications\", field: \"created_at\", agg: \"min\" }, \"asc\"]]\n *\n * // How many applications each candidate has.\n * orderBy: [[{ relation: \"applications\", agg: \"count\" }, \"desc\"]]\n * ```\n *\n * This is the half of a queue that cannot be worked around client-side. A\n * *filter* over a relation can be approximated by denormalising a flag onto the\n * row; an *ordering* cannot be approximated at all once the result set is\n * paged, because the client only ever holds one page and the page was chosen by\n * the wrong order.\n *\n * Rows the relation reaches nothing from sort last ascending and first\n * descending — the placement Postgres gives a `NULL`, stated rather than\n * inherited, because the keyset comparison behind cursor paging has to agree\n * with it exactly. Ties are broken by the row id, so the order is total and\n * paging over it neither repeats nor skips.\n *\n * Compiled by the driver into a correlated subquery, so it is subject to the\n * reader's own row-level security on the target table: a related row the reader\n * cannot see does not contribute to the aggregate. Offered only where\n * {@link DataSourceCapabilities.relationAggregateSorts} says the driver can\n * compile it.\n *\n * @group Models\n */\nexport interface RelationAggregateSort {\n    /** The to-many relation to aggregate over, by its name on this collection. */\n    relation: string;\n\n    /** The aggregate to apply. */\n    agg: RelationAggregateFn;\n\n    /**\n     * The column of the *target* to aggregate. Required by every function\n     * except `count`, which counts the related rows themselves when it is\n     * omitted — and counts the rows whose column is non-null when it is not.\n     */\n    field?: string;\n}\n\n/** The wire spelling of a {@link RelationAggregateSort}: `min(applications.created_at)`. */\nconst RELATION_AGGREGATE_SORT_PATTERN = /^(min|max|count|sum|avg)\\(([^().]+)(?:\\.([^()]+))?\\)$/;\n\n/**\n * A {@link RelationAggregateSort} as a single string — `min(applications.created_at)`,\n * `count(applications)`.\n *\n * The wire form is a string because every layer below the call site already is\n * one: `OrderByTuple` is `[string, direction]`, the REST parameter is\n * `?orderBy=key:direction`, the driver contract takes `orderBy?: string |\n * OrderByTuple[]`, and a cursor names its keys by string. `_score` established\n * the same pattern — a sort key that is not a column, spelled as one — and this\n * reuses it rather than widening five signatures to carry an object that would\n * be flattened at the end anyway.\n *\n * SQL's own spelling, so the key reads as what it compiles to. Neither `:` nor\n * `,` appears in it, which is what keeps it safe in the colon-delimited wire\n * shorthand.\n *\n * @group Models\n */\nexport function encodeRelationAggregateSort(sort: RelationAggregateSort): string {\n    return `${sort.agg}(${sort.relation}${sort.field ? `.${sort.field}` : \"\"})`;\n}\n\n/**\n * Read the string spelling back, or `undefined` if it is not one.\n *\n * `undefined` rather than a throw: this is asked of *every* sort key to find\n * out which kind it is, and an ordinary column name is not an error.\n *\n * @group Models\n */\nexport function parseRelationAggregateSort(key: string): RelationAggregateSort | undefined {\n    const match = RELATION_AGGREGATE_SORT_PATTERN.exec(key);\n    if (!match) return undefined;\n    const [, agg, relation, field] = match;\n    // `min()` and friends have nothing to aggregate without a column, and a\n    // key that parses to a half-built sort would resolve to no expression and\n    // be dropped — leaving the rows unsorted while the caller believes\n    // otherwise. `count` is the one function that means something on its own.\n    if (!field && agg !== \"count\") return undefined;\n    return { agg: agg as RelationAggregateFn, relation, ...(field && { field }) };\n}\n\n/** Is this sort key the object form rather than a field name? */\nexport function isRelationAggregateSort(key: unknown): key is RelationAggregateSort {\n    return typeof key === \"object\" && key !== null &&\n        typeof (key as RelationAggregateSort).relation === \"string\" &&\n        typeof (key as RelationAggregateSort).agg === \"string\";\n}\n\n/** A sort key in the single-string form every layer below the call site speaks. */\nexport function sortKeyToString(key: SortKey): string {\n    return isRelationAggregateSort(key) ? encodeRelationAggregateSort(key) : key;\n}\n\n/**\n * Canonical filter operators supported across all database backends.\n * Each DB driver translates these to its native query format.\n *\n * @group Models\n */\nexport type WhereFilterOp =\n    | \"<\"\n    | \"<=\"\n    | \"==\"\n    | \"!=\"\n    | \">=\"\n    | \">\"\n    | \"array-contains\"\n    | \"in\"\n    | \"not-in\"\n    | \"array-contains-any\"\n    | \"like\"\n    | \"ilike\"\n    | \"not-like\"\n    | \"not-ilike\"\n    | \"is-null\"\n    | \"is-not-null\";\n\n/**\n * Used to define filters applied in collections.\n *\n * A single condition is a tuple `[operator, value]`.\n * Multiple conditions on the same field use an array of tuples.\n *\n * @example\n * // Single condition per field\n * { status: [\"==\", \"active\"], price: [\">=\", 9.99] }\n *\n * // Multiple conditions on one field\n * { age: [[\">=\", 18], [\"<\", 65]] }\n *\n * // Array operators\n * { role: [\"in\", [\"admin\", \"editor\"]] }\n * { tags: [\"array-contains\", \"featured\"] }\n *\n * // Pattern matching (SQL wildcards: % and _)\n * { name: [\"ilike\", \"%john%\"] }\n * { slug: [\"like\", \"post-%\"] }\n *\n * // Null checks (the value is ignored; `null` is conventional)\n * { deleted_at: [\"is-null\", null] }\n * { published_at: [\"is-not-null\", null] }\n *\n * @group Models\n */\nexport type FilterValues<Key extends string> =\n    Partial<Record<Key, [WhereFilterOp, unknown] | [WhereFilterOp, unknown][]>>;\n\n/**\n * The field names a query may address on a row type: every column, plus a\n * dotted path reaching inside one — or *through a relation* to a column of the\n * related row.\n *\n * A dotted path is not checked at all, in either direction. That is a\n * deliberate loosening, and it is worth being exact about what it costs. The\n * root used to be checked: `\"meta.tag\"` required a `meta` column. It cannot\n * stay checked, because the other thing a dotted path now means is\n * `\"applications.status\"` — and `applications` is a *relation*, which comes\n * from the collection's `relations` and is not a column of `M` at all. There is\n * nothing in a generated row type that could validate one. `FindParams.include`\n * is `string[]` for exactly this reason and says so.\n *\n * So the guarantee moves rather than disappears: an unresolvable path is a 400\n * from the driver, not a silently dropped condition. See\n * `UnknownFilterFieldsMode` in `@rebasepro/server-postgres` — dropping a filter\n * key *widens* the read to every row, which is why that resolution fails\n * closed. A typo'd relation path is refused at runtime with the target\n * collection's real column list in the message.\n *\n * Undotted keys are unaffected and still checked against `keyof M`.\n *\n * When `M` is left at its default `Record<string, unknown>`, `keyof M` is\n * `string` and this collapses to `string`, so every query stays permissive.\n * That is what keeps an untyped `createRebaseClient()` behaving exactly as it\n * did before the row type was threaded through.\n *\n * @group Models\n */\nexport type FieldPath<M extends Record<string, unknown> = Record<string, unknown>> =\n    | Extract<keyof M, string>\n    | `${string}.${string}`;\n\n/**\n * Relaxed filter type that also accepts pre-serialized PostgREST strings.\n * **Internal only** — used at the wire-format boundary\n * (`serializeFilter` / `deserializeFilter` in `@rebasepro/common`).\n *\n * Application code, UI components, and SDK consumers should use\n * {@link FilterValues} instead.\n *\n * @internal\n */\nexport type WireFilterValues<Key extends string> =\n    Partial<Record<Key, [WhereFilterOp, unknown] | [WhereFilterOp, unknown][] | string>>;\n\n/**\n * A pre-defined filter preset for quick access in the collection toolbar.\n * Users can select a preset to instantly apply a set of filters and\n * optionally a sort order.\n *\n * @group Models\n */\nexport interface FilterPreset<Key extends string = string> {\n    /**\n     * Display label shown in the preset menu.\n     * If omitted, a summary is auto-generated from the filter keys.\n     */\n    label?: string;\n\n    /**\n     * The filter values to apply when this preset is selected.\n     */\n    filterValues: FilterValues<Key>;\n\n    /**\n     * Optional sort override to apply alongside the filter values.\n     * One key, or several in order of significance.\n     */\n    sort?: OrderBySpec<Key>;\n}\n\n/**\n * PostgREST short-code operators. Wire format only — these never appear\n * in application code. Used by `serializeFilter`/`deserializeFilter`\n * in `@rebasepro/common`.\n */\nexport type RestFilterOp =\n    | \"eq\" | \"neq\"\n    | \"gt\" | \"gte\"\n    | \"lt\" | \"lte\"\n    | \"in\" | \"nin\"\n    | \"cs\" | \"csa\"\n    | \"like\" | \"ilike\"\n    | \"nlike\" | \"nilike\"\n    | \"isnull\" | \"notnull\";\n\n/** Maps canonical operators to their REST short-code equivalents. */\nexport const CANONICAL_TO_REST: Readonly<Record<WhereFilterOp, RestFilterOp>> = {\n    \"==\": \"eq\",\n    \"!=\": \"neq\",\n    \">\": \"gt\",\n    \">=\": \"gte\",\n    \"<\": \"lt\",\n    \"<=\": \"lte\",\n    \"in\": \"in\",\n    \"not-in\": \"nin\",\n    \"array-contains\": \"cs\",\n    \"array-contains-any\": \"csa\",\n    \"like\": \"like\",\n    \"ilike\": \"ilike\",\n    \"not-like\": \"nlike\",\n    \"not-ilike\": \"nilike\",\n    \"is-null\": \"isnull\",\n    \"is-not-null\": \"notnull\"\n};\n\n/** Maps REST short-code operators to their canonical equivalents. */\nexport const REST_TO_CANONICAL: Readonly<Record<RestFilterOp, WhereFilterOp>> = {\n    \"eq\": \"==\",\n    \"neq\": \"!=\",\n    \"gt\": \">\",\n    \"gte\": \">=\",\n    \"lt\": \"<\",\n    \"lte\": \"<=\",\n    \"in\": \"in\",\n    \"nin\": \"not-in\",\n    \"cs\": \"array-contains\",\n    \"csa\": \"array-contains-any\",\n    \"like\": \"like\",\n    \"ilike\": \"ilike\",\n    \"nlike\": \"not-like\",\n    \"nilike\": \"not-ilike\",\n    \"isnull\": \"is-null\",\n    \"notnull\": \"is-not-null\"\n};\n\n/**\n * Operators that test for null/not-null and therefore ignore their value.\n * Codecs normalize the value of these conditions to `null`.\n */\nexport const NULL_OPS: ReadonlySet<WhereFilterOp> = new Set<WhereFilterOp>([\n    \"is-null\", \"is-not-null\"\n]);\n\n/**\n * Every canonical operator, in a stable order. Useful for engine capability\n * declarations ({@link DataSourceCapabilities.filterOperators}) and for\n * building operator subsets.\n * @group Models\n */\nexport const ALL_WHERE_FILTER_OPS: readonly WhereFilterOp[] = [\n    \"<\", \"<=\", \"==\", \"!=\", \">=\", \">\",\n    \"in\", \"not-in\",\n    \"array-contains\", \"array-contains-any\",\n    \"like\", \"ilike\", \"not-like\", \"not-ilike\",\n    \"is-null\", \"is-not-null\"\n];\n\n/** All canonical operator strings for runtime validation. */\nconst CANONICAL_OPS: ReadonlySet<string> = new Set<WhereFilterOp>(ALL_WHERE_FILTER_OPS);\n\n/**\n * The REST table as a `Map`, because the key `toCanonicalOp` is handed comes\n * off the wire.\n *\n * Indexed as a plain object, every `Object.prototype` member answered:\n * `toCanonicalOp(\"valueOf\")` returned the inherited *function* as though it\n * were a `WhereFilterOp`, and every caller here treats a defined result as\n * \"known operator\". Same defect the REST codec's own lookup tables were\n * converted away from in `filter-dialect.ts`; this is the copy that survived\n * one package over, and it now sits under the operator validation the REST\n * parser does, which would otherwise have admitted `[\"constructor\", x]`.\n */\nconst REST_OP_LOOKUP: ReadonlyMap<string, WhereFilterOp> = new Map<string, WhereFilterOp>(\n    Object.entries(REST_TO_CANONICAL) as [string, WhereFilterOp][]\n);\n\n/**\n * Resolve any operator string (canonical or REST short-code) to its\n * canonical `WhereFilterOp` form. Returns `undefined` for unknown operators.\n *\n * @example\n * toCanonicalOp(\"==\")   // \"==\"\n * toCanonicalOp(\"eq\")   // \"==\"\n * toCanonicalOp(\"cs\")   // \"array-contains\"\n * toCanonicalOp(\"xyz\")  // undefined\n */\nexport function toCanonicalOp(op: string): WhereFilterOp | undefined {\n    if (CANONICAL_OPS.has(op)) return op as WhereFilterOp;\n    return REST_OP_LOOKUP.get(op);\n}\n","import { ALL_WHERE_FILTER_OPS, WhereFilterOp } from \"./filter-operators\";\n\n/**\n * Describes the capabilities and features supported by a data source (driver).\n *\n * Each driver (Postgres, Firebase, MongoDB, etc.) declares which features it\n * supports. The admin uses this descriptor to:\n * - Show/hide editor tabs (e.g. Relations for SQL, Subcollections for Firebase)\n * - Filter the property type picker (e.g. `relation` for SQL, `reference` for Firebase)\n * - Toggle driver-specific form controls (e.g. `columnType` for SQL)\n *\n * @group Models\n */\nexport interface DataSourceCapabilities {\n    /** Unique driver key (e.g. \"postgres\", \"firestore\", \"mongodb\") */\n    key: string;\n\n    /** Human-readable label for the UI (e.g. \"PostgreSQL\", \"Firebase / Firestore\") */\n    label: string;\n\n    // ── Feature flags ─────────────────────────────────────────────────\n    /** Does this source support SQL-style relations (JOINs)? */\n    supportsRelations: boolean;\n\n    /** Does this source support nested subcollections? */\n    supportsSubcollections: boolean;\n\n    /** Does this source support Row Level Security policies? */\n    supportsRLS: boolean;\n\n    /** Does this source support document references (Firebase-style)? */\n    supportsReferences: boolean;\n\n    /** Does this source support SQL column type annotations? */\n    supportsColumnTypes: boolean;\n\n    /** Does this source support real-time listeners? */\n    supportsRealtime: boolean;\n\n    /**\n     * Does this source store vectors natively?\n     *\n     * `VectorProperty` carries a `dimensions` and is pgvector-shaped. It was\n     * the one driver-specific property kind with no flag to gate it, so unlike\n     * every other field in this descriptor there was not even a runtime answer\n     * to appeal to — a Firestore collection could declare an embedding column\n     * and no driver would do anything with it.\n     */\n    supportsVectors: boolean;\n\n    /**\n     * Canonical filter operators this engine can execute.\n     *\n     * The admin UI intersects this set with the property-type defaults and\n     * any per-property narrowing (`property.ui.filterOperators`) to decide\n     * which operators to offer in filter fields — so an engine that cannot\n     * run `ilike` (e.g. Firestore) never shows a \"Contains\" filter that\n     * would throw at query time.\n     */\n    filterOperators: readonly WhereFilterOp[];\n\n    /**\n     * Relation kinds this engine's driver can compile into a filter.\n     *\n     * Only `belongsTo` puts a column on the row being filtered; the others are\n     * answered with a correlated subquery over the junction or the target\n     * table, which not every driver can build. An engine with no relations at\n     * all declares none.\n     *\n     * The admin uses this to decide whether a relation column offers a filter\n     * control. Offering one an engine cannot answer is not cosmetic: a driver\n     * that drops the key it cannot resolve *widens* the read to every row, and\n     * one that fails closed answers a control the admin itself put on screen\n     * with a 400.\n     *\n     * Optional, so a third-party driver registered before this existed still\n     * compiles. Omitted means {@link DEFAULT_FILTERABLE_RELATION_KINDS} — the\n     * one kind that is a plain column comparison, which every relational\n     * driver can do. The subquery kinds are a real capability and have to be\n     * claimed rather than assumed: assuming them wrongly is the widening.\n     */\n    filterableRelationKinds?: readonly string[];\n\n    /**\n     * Can a filter address a *column of the related row* — `applications.status`\n     * — rather than only the related row's id?\n     *\n     * A separate capability from {@link filterableRelationKinds} because it is\n     * a separate subquery: the id filter stops at the junction, one of these\n     * reaches the target table and compares one of its columns. A driver can\n     * do the first and not the second.\n     *\n     * Optional and defaulting to **false**, for the reason the relation kinds\n     * default narrow: an unclaimed capability that the admin assumes is there\n     * produces a control whose query the driver answers by dropping the key —\n     * and a dropped filter key widens the read to every row.\n     *\n     * Meaningless without {@link supportsRelations}; a driver with no relations\n     * has nothing to reach through.\n     */\n    supportsRelationFieldFilters?: boolean;\n\n    /**\n     * Can a sort key be an aggregate over a to-many relation — \"oldest waiting\n     * first\", \"busiest first\"?\n     *\n     * Compiled as a correlated scalar subquery in `ORDER BY`, which a document\n     * store cannot express at all. Optional and defaulting to **false**.\n     *\n     * A wrongly claimed sort capability fails differently from a wrongly\n     * claimed filter one, and worse in one respect: a driver that cannot\n     * resolve the key drops the `ORDER BY` and answers 200 with rows in\n     * whatever order the database pleased, which reads as a sorted list. Paging\n     * over that repeats and skips rows.\n     */\n    relationAggregateSorts?: boolean;\n\n    // ── Admin capability flags ───────────────────────────────────────\n    /** Does this source support SQL admin operations (SQL editor, EXPLAIN, etc.)? */\n    supportsSQLAdmin: boolean;\n\n    /** Does this source support document admin operations (aggregation, stats)? */\n    supportsDocumentAdmin: boolean;\n\n    /** Does this source support schema admin (unmapped tables, table metadata)? */\n    supportsSchemaAdmin: boolean;\n}\n\n/**\n * Subset of DataSourceCapabilities containing only feature flags.\n * Useful when you only need to check capabilities without UI metadata.\n * @group Models\n */\nexport type DataSourceFeatures = Omit<DataSourceCapabilities, \"key\" | \"label\">;\n\n/**\n * The default data-source key, used when a collection does not name a\n * `dataSource`. Shared by the frontend router and the backend driver\n * registry so both agree on \"the default database\".\n * @group Models\n */\nexport const DEFAULT_DATA_SOURCE_KEY = \"(default)\";\n\n/**\n * How the *frontend* reaches a data source.\n *\n * - `\"server\"` — through the Rebase backend (the `RebaseClient`). The backend\n *   holds the actual database adapter and routes by data-source key. This is\n *   the default and covers Postgres, MongoDB, and any other server-mediated\n *   engine.\n * - `\"direct\"` — straight from the client to the external backend via its own\n *   SDK driver (e.g. Firestore). The Rebase backend is not in the data path.\n * - `\"custom\"` — a developer-supplied {@link DataDriver}, transport unspecified.\n *\n * @group Models\n */\nexport type DataSourceTransport = \"server\" | \"direct\" | \"custom\";\n\n/**\n * Declarative definition of a data source — a named place data lives.\n *\n * Declared once and shared front and back: the frontend uses it to decide\n * transport (client vs direct driver), the backend uses the same `key` to\n * resolve a database adapter, and the editor derives capabilities from\n * `engine`. Collections reference a definition by its `key` via\n * `collection.dataSource`.\n *\n * @group Models\n */\nexport interface DataSourceDefinition {\n    /**\n     * Unique identifier for this data source. Collections point at it via\n     * `dataSource`. Defaults to {@link DEFAULT_DATA_SOURCE_KEY}.\n     */\n    key: string;\n\n    /**\n     * The engine backing this data source (e.g. `\"postgres\"`, `\"mongodb\"`,\n     * `\"firestore\"`, or a custom id). Determines the\n     * {@link DataSourceCapabilities} surfaced in the editor.\n     */\n    engine: string;\n\n    /**\n     * How the frontend reaches this source. Optional — when omitted it is\n     * inferred: `\"direct\"` if the definition carries a client-side driver,\n     * `\"server\"` otherwise.\n     */\n    transport?: DataSourceTransport;\n\n    /**\n     * The physical database/schema/Firestore-database within the engine.\n     * Threaded to drivers/adapters as the existing `databaseId` runtime\n     * parameter. Defaults to the engine's own default.\n     */\n    databaseId?: string;\n\n    /** Human-readable label for the UI. */\n    label?: string;\n}\n\n/**\n * The resolved data source for a collection: the single source of truth that\n * the frontend router, backend registry, and editor all derive from.\n * Produced by `resolveDataSource(collection, registry)`.\n *\n * @group Models\n */\nexport interface ResolvedDataSource {\n    /** Data-source key (routing key, shared front + back). */\n    key: string;\n    /** Engine backing the source (drives capabilities). */\n    engine: string;\n    /** Frontend transport. */\n    transport: DataSourceTransport;\n    /** Within-engine instance, if any (the `databaseId` runtime param). */\n    databaseId?: string;\n    /** Capabilities derived from {@link engine}. */\n    capabilities: DataSourceCapabilities;\n}\n\n/**\n * Relation kinds assumed filterable when a driver does not say.\n *\n * `belongsTo` alone: its filter is a comparison on a column of the row being\n * filtered, the one shape that needs no query construction a driver might not\n * have. Everything else is a correlated subquery over another table.\n *\n * @group Models\n */\nexport const DEFAULT_FILTERABLE_RELATION_KINDS: readonly string[] = [\"belongsTo\"];\n\n// ── Built-in driver capabilities ─────────────────────────────────────\n\n/** @group Models */\nexport const POSTGRES_CAPABILITIES: DataSourceCapabilities = {\n    key: \"postgres\",\n    label: \"PostgreSQL\",\n    supportsRelations: true,\n    supportsSubcollections: false,\n    supportsRLS: true,\n    supportsReferences: false,\n    supportsColumnTypes: true,\n    supportsRealtime: true,\n    supportsVectors: true,\n    filterOperators: ALL_WHERE_FILTER_OPS,\n    // `via` is absent: its join path is authored source → target with no\n    // stated inverse, so the driver has nothing to reverse into a filter.\n    filterableRelationKinds: [\"belongsTo\", \"manyToMany\", \"hasMany\", \"hasOne\"],\n    supportsRelationFieldFilters: true,\n    relationAggregateSorts: true,\n    supportsSQLAdmin: true,\n    supportsDocumentAdmin: false,\n    supportsSchemaAdmin: true\n};\n\n/** @group Models */\nexport const FIREBASE_CAPABILITIES: DataSourceCapabilities = {\n    key: \"firestore\",\n    label: \"Firebase / Firestore\",\n    supportsRelations: false,\n    supportsSubcollections: true,\n    supportsRLS: false,\n    supportsReferences: true,\n    supportsColumnTypes: false,\n    supportsRealtime: true,\n    supportsVectors: false,\n    // Firestore has no SQL pattern matching — the driver throws on the LIKE\n    // family, so the UI must never offer it.\n    filterOperators: ALL_WHERE_FILTER_OPS.filter(op =>\n        op !== \"like\" && op !== \"ilike\" && op !== \"not-like\" && op !== \"not-ilike\"),\n    // No relations at all — a document store links by reference. Nothing to\n    // reach through, so neither of the two relation-reaching features either.\n    filterableRelationKinds: [],\n    supportsRelationFieldFilters: false,\n    relationAggregateSorts: false,\n    supportsSQLAdmin: false,\n    supportsDocumentAdmin: false,\n    supportsSchemaAdmin: false\n};\n\n/** @group Models */\nexport const MONGODB_CAPABILITIES: DataSourceCapabilities = {\n    key: \"mongodb\",\n    label: \"MongoDB\",\n    supportsRelations: false,\n    supportsSubcollections: true,\n    supportsRLS: false,\n    supportsReferences: true,\n    supportsColumnTypes: false,\n    supportsRealtime: false,\n    supportsVectors: false,\n    filterOperators: ALL_WHERE_FILTER_OPS,\n    filterableRelationKinds: [],\n    supportsRelationFieldFilters: false,\n    relationAggregateSorts: false,\n    supportsSQLAdmin: false,\n    supportsDocumentAdmin: true,\n    supportsSchemaAdmin: true\n};\n\n/**\n * Fallback capabilities when the driver is unknown.\n * Enables everything so nothing is hidden unexpectedly.\n * @group Models\n */\nexport const DEFAULT_CAPABILITIES: DataSourceCapabilities = {\n    key: \"(default)\",\n    label: \"Default\",\n    supportsRelations: true,\n    supportsSubcollections: true,\n    supportsRLS: true,\n    supportsReferences: true,\n    supportsColumnTypes: true,\n    supportsRealtime: true,\n    supportsVectors: true,\n    filterOperators: ALL_WHERE_FILTER_OPS,\n    // The exception to this descriptor's \"enable everything\" rule. The other\n    // flags hide a tab or a picker when they are wrong; this one decides\n    // whether a query is sent that an unknown driver may answer by dropping\n    // the condition — which returns every row rather than none.\n    filterableRelationKinds: DEFAULT_FILTERABLE_RELATION_KINDS,\n    // Narrow for the same reason, and more sharply. An unknown driver that is\n    // assumed to compile these answers by dropping the key: the filter widens\n    // the read to every row, and the sort comes back unordered while looking\n    // sorted. Both have to be claimed.\n    supportsRelationFieldFilters: false,\n    relationAggregateSorts: false,\n    supportsSQLAdmin: true,\n    supportsDocumentAdmin: true,\n    supportsSchemaAdmin: true\n};\n\nconst CAPABILITIES_REGISTRY: Record<string, DataSourceCapabilities> = {\n    postgres: POSTGRES_CAPABILITIES,\n    firestore: FIREBASE_CAPABILITIES,\n    mongodb: MONGODB_CAPABILITIES,\n    \"(default)\": DEFAULT_CAPABILITIES\n};\n\n/**\n * Look up capabilities for a given engine key.\n * If `engine` is undefined or not found, returns `DEFAULT_CAPABILITIES`.\n * @group Models\n */\nexport function getDataSourceCapabilities(engine?: string): DataSourceCapabilities {\n    if (!engine) return POSTGRES_CAPABILITIES; // postgres is the default engine\n    return CAPABILITIES_REGISTRY[engine] ?? DEFAULT_CAPABILITIES;\n}\n\n/**\n * Register custom capabilities for a third-party driver.\n * @group Models\n */\nexport function registerDataSourceCapabilities(capabilities: DataSourceCapabilities): void {\n    CAPABILITIES_REGISTRY[capabilities.key] = capabilities;\n}\n","import type { CollectionCallbacks } from \"./entity_callbacks\";\n\nimport type { EnumValues, Properties, PostgresProperties, FirebaseProperties, MongoProperties } from \"./properties\";\n\nimport type { User } from \"../users\";\nimport type { Relation } from \"./relations\";\nimport type { SecurityRule } from \"./security_rules\";\nimport { getDataSourceCapabilities } from \"./data_source\";\nimport type { WhereFilterOp, FilterValues, FilterPreset } from \"./filter-operators\";\nimport type { SearchConfig } from \"./search\";\n\n/**\n * Base interface containing all driver-agnostic collection properties.\n * Use {@link PostgresCollectionConfig} or {@link FirebaseCollectionConfig} for\n * driver-specific type safety, or {@link CollectionConfig} when you\n * need to handle any collection regardless of backend.\n *\n * @group Models\n */\nexport interface BaseCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User> {\n\n    /**\n     * The collection's identity. Required, and the value nearly everything else\n     * keys on:\n     *\n     * - the REST path — `/api/data/<slug>`\n     * - the SDK accessor — `client.data.<slug>` / `client.data.collection(\"<slug>\")`\n     * - the admin panel's URL\n     * - the target of a `reference` or `relation` property\n     *\n     * Conventionally kebab-case and plural (`blog-posts`). It is independent of\n     * {@link table}: the slug is what callers say, the table is where the rows\n     * live, and renaming one does not rename the other.\n     *\n     * Treat it as frozen once anything has shipped against it — changing a slug\n     * changes every URL and every generated accessor at once.\n     *\n     * @example\n     * defineCollection({\n     *     slug: \"blog-posts\",   // /api/data/blog-posts, client.data.blogPosts\n     *     table: \"posts\",\n     *     properties: { … }\n     * })\n     */\n    slug: string;\n\n    /**\n     * Name of the collection, typically plural.\n     * E.g. `Products`, `Blog`\n     */\n    name: string;\n\n    /**\n     * Singular name of an entry in this collection\n     * E.g. `Product`, `Blog entry`\n     */\n    singularName?: string;\n\n    /**\n     * Optional description of this view. You can use Markdown.\n     */\n    description?: string;\n\n    /**\n     * Child collections nested under entities of this collection.\n     * Populated automatically during normalization from driver-specific fields\n     * (e.g. Firebase `subcollections`, Postgres `relations` with many-cardinality).\n     *\n     * Custom drivers can set this directly to expose child collections to the UI.\n     */\n    childCollections?: () => CollectionConfig<Record<string, unknown>>[];\n\n\n    /**\n     * The data source this collection belongs to — the routing key shared by\n     * the frontend router and the backend driver registry. It points at a\n     * {@link DataSourceDefinition} registered on `<Rebase dataSources>` (front)\n     * and `initializeRebaseBackend({ dataSources })` (back).\n     *\n     * If not specified, the default data source `\"(default)\"` is used, which\n     * for a standard Rebase app is the server-mediated Postgres backend.\n     *\n     * @example\n     * // Default data source (server-mediated Postgres)\n     * { slug: \"products\" }\n     *\n     * // A direct-transport Firestore data source registered as \"analytics\"\n     * { slug: \"events\", dataSource: \"analytics\" }\n     */\n    dataSource?: string;\n\n    /**\n     * The database engine backing this collection (`\"postgres\"`, `\"firestore\"`,\n     * `\"mongodb\"`, or a custom id).\n     *\n     * On concrete collection types ({@link PostgresCollectionConfig},\n     * {@link FirebaseCollectionConfig}, {@link MongoDBCollectionConfig}) this is a literal\n     * discriminant. On the base type it is optional and gets stamped\n     * automatically during collection normalization from the registered\n     * {@link DataSourceDefinition}.\n     *\n     * Prefer setting {@link dataSource} and letting the engine be resolved.\n     */\n    engine?: string;\n\n    /**\n     * Which database within the engine.\n     * - For Firestore: The Firestore database ID (e.g., for multi-database projects)\n     * - For PostgreSQL: Schema or database name\n     * - For MongoDB: Database name\n     *\n     * If not specified, the default database of the engine is used. Resolved\n     * from the collection's {@link DataSourceDefinition} when omitted here.\n     */\n    databaseId?: string;\n\n    /**\n     * Set of properties that compose a entity\n     */\n    properties: Properties;\n\n\n\n\n\n\n\n\n\n\n\n\n    /**\n     * Mark this collection as an authentication collection.\n     * When true, this collection is used for user management, login, password hashing, and invitation flows.\n     */\n    auth?: boolean | AuthCollectionConfig;\n\n\n\n\n\n\n\n    /**\n     * Row-level authorization rules for this collection.\n     *\n     * Driver-agnostic on purpose, unlike `disableDefaultPolicies`, `table` and\n     * `relations`, which are declared on {@link PostgresCollectionConfig} only.\n     * The rules are a *contract* — who may read or write which rows — and each\n     * engine enforces it its own way:\n     *\n     * - **Postgres** compiles them to real `CREATE POLICY` statements and lets\n     *   the database enforce them (see {@link PostgresCollectionConfig.securityRules},\n     *   which narrows this with the raw-SQL details).\n     * - **MongoDB** translates them into a query filter it AND-s into every\n     *   read and write, honouring `access`, `ownerField`, `roles`, `mode` and\n     *   the `operation`/`operations` selectors, and making a best effort at raw\n     *   `using`/`withCheck` SQL.\n     * - **Firestore** does not implement them at all; its own rules language is\n     *   evaluated by Google, not from here. `supportsRLS` on\n     *   {@link DataSourceCapabilities} reports which engines generate policies,\n     *   which is not the same question as whether an engine honours a rule.\n     */\n    securityRules?: readonly SecurityRule[];\n\n    /**\n     * This interface defines all the callbacks that can be used when a entity\n     * is being created, updated or deleted.\n     * Useful for adding your own logic or blocking the execution of the operation.\n     */\n    readonly callbacks?: CollectionCallbacks<M, USER>;\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n    /**\n     * User id of the owner of this collection. This is used only by plugins, or if you\n     * are writing custom code\n     */\n    ownerId?: string;\n\n    /**\n     * Arbitrary key-value metadata for external consumers.\n     * Not interpreted by Rebase — passed through serialization unchanged.\n     * Used by domain apps to store custom per-collection config.\n     */\n    metadata?: Record<string, unknown>;\n\n\n\n\n    /**\n     * If set to true, changes to the entity will be saved in a subcollection.\n     * This prop has no effect if the history plugin is not enabled\n     */\n    history?: boolean;\n\n    /**\n     * Whether a write naming a field this collection does not declare is\n     * rejected with a 400. Defaults to `true`.\n     *\n     * Set to `false` where a column really does exist that the config never\n     * declared — populated by a trigger, or introspected rather than declared —\n     * and callers need to write it. The column still has to exist: the driver\n     * checks the key against the table's own columns whatever this is set to,\n     * because a key with no column behind it is not passed to the database and\n     * refused, it is dropped from the statement and answered 201.\n     *\n     * It does not let a typo through to Postgres for Postgres to judge. That is\n     * what this flag was documented as doing, and no such judgment ever\n     * happened.\n     */\n    strictWrites?: boolean;\n\n\n\n\n\n\n\n\n}\n\n// ── Driver-specific collection types ──────────────────────────────────\n\n/**\n * A collection backed by PostgreSQL (or any SQL database).\n * Adds support for SQL-style relations (JOINs) and Row Level Security.\n *\n * Use this type instead of {@link CollectionConfig} when you want\n * compile-time safety that only SQL-relevant fields appear.\n *\n * @group Models\n */\nexport interface PostgresCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>\n    extends BaseCollectionConfig<M, USER> {\n    properties: PostgresProperties;\n\n    /**\n     * The database engine for this collection. For Postgres collections this\n     * can be omitted (Postgres is the default) or set to `\"postgres\"`.\n     */\n    engine?: \"postgres\" | undefined;\n\n    /**\n     * The PostgreSQL table name for this collection.\n     */\n    table: string;\n\n    /**\n     * The PostgreSQL schema name for this table.\n     * E.g. \"public\", \"rebase\", \"auth\".\n     * If not specified, \"public\" is used (or the default search path).\n     */\n    schema?: string;\n\n    /**\n     * For SQL databases, you can define the relations between collections here.\n     * Relations describe JOINs, foreign keys, and junction tables.\n     */\n    relations?: Relation[];\n\n    /**\n     * Security rules for this collection (PostgreSQL Row Level Security).\n     * When defined, the schema generator will enable RLS on the table and\n     * create the corresponding PostgreSQL policies.\n     *\n     * Supports three levels of expressiveness:\n     * 1. **Convenience shortcuts** — `ownerField`, `access`, `roles`\n     * 2. **Raw SQL** — `using` and `withCheck` for full PostgreSQL power\n     * 3. **Combined** — mix shortcuts with `roles` for common patterns\n     *\n     * The authenticated user context is available in raw SQL via:\n     * - `auth.uid()`   — the current user's ID\n     * - `auth.roles()` — comma-separated app role IDs\n     * - `auth.jwt()`   — full JWT claims as JSONB\n     */\n    securityRules?: readonly SecurityRule[];\n\n    /**\n     * Opt out of the framework's default Row Level Security policies.\n     *\n     * The schema generator automatically injects, for every collection, a\n     * baseline SELECT policy granting the trusted server context and the\n     * `admin` role read access (reads run under a restricted role, so RLS\n     * default-denies without it). For auth collections it additionally injects\n     * a self-read policy (`id = auth.uid()`) and an admin-only write gate\n     * (INSERT/UPDATE/DELETE require the `admin` role or the trusted server\n     * context), making privileged columns such as `roles` safe by default.\n     *\n     * Author-defined `securityRules` are permissive and broaden access on top\n     * of these defaults. Set this flag to `true` to remove the defaults\n     * entirely and take full responsibility for the collection's RLS.\n     *\n     * @default false\n     */\n    disableDefaultPolicies?: boolean;\n\n    /**\n     * Opt in to Postgres full-text search for this collection.\n     *\n     * Omit it and `.search()` keeps its existing behaviour exactly — an\n     * `ILIKE '%term%'` across top-level string properties. Declare it and the\n     * collection gains one generated `tsvector` column and a GIN index, and\n     * `.search()` compiles to a ranked `@@ websearch_to_tsquery` against them.\n     *\n     * Postgres-only, like {@link VectorProperty}: the block is rejected at boot\n     * on other engines rather than silently ignored.\n     *\n     * @see SearchConfig\n     */\n    search?: SearchConfig;\n}\n\n/**\n * A collection backed by Firebase / Firestore.\n * Adds support for subcollections (nested document collections).\n *\n * Use this type instead of {@link CollectionConfig} when you want\n * compile-time safety that only Firestore-relevant fields appear.\n *\n * @group Models\n */\nexport interface FirebaseCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>\n    extends BaseCollectionConfig<M, USER> {\n    /**\n     * The database engine for this collection. Must be set to `\"firestore\"`.\n     */\n    engine: \"firestore\";\n\n    /**\n     * Set of properties that compose a entity.\n     * Firestore collections support `reference` properties but not `relation`.\n     */\n    properties: FirebaseProperties;\n\n    /**\n     * The Firestore collection path to query. Defaults to `slug` if not set.\n     * Use this when the Firestore path differs from the slug\n     * (e.g., when a PostgreSQL collection already uses the same slug).\n     *\n     * @example\n     * ```typescript\n     * const fsCustomer: FirebaseCollectionConfig = {\n     *     slug: \"fs_customer\",        // URL: /c/fs_customer\n     *     path: \"customer\",           // Firestore path: customer\n     *     name: \"Customers (Firestore)\",\n     *     engine: \"firestore\",\n     *     properties: { ... }\n     * };\n     * ```\n     */\n    path?: string;\n\n    /**\n     * You can add subcollections to your entity in the same way you define the root\n     * collections. The collections added here will be displayed when opening\n     * the side dialog of a entity.\n     */\n    subcollections?: () => CollectionConfig<Record<string, unknown>>[];\n}\n\n/**\n * A collection backed by MongoDB.\n *\n * Use this type instead of {@link CollectionConfig} when you want\n * compile-time safety that only MongoDB-relevant fields appear.\n *\n * @group Models\n */\nexport interface MongoDBCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>\n    extends BaseCollectionConfig<M, USER> {\n\n    /**\n     * The database engine for this collection. Must be set to `\"mongodb\"`.\n     */\n    engine: \"mongodb\";\n\n    /**\n     * Set of properties that compose a entity.\n     * MongoDB collections support `reference` properties but not `relation`.\n     */\n    properties: MongoProperties;\n\n    /**\n     * The MongoDB collection name to use. Defaults to `slug` if not set.\n     * Use this when the MongoDB collection name differs from the slug\n     * (e.g., when a PostgreSQL collection already uses the same slug).\n     *\n     * @example\n     * ```typescript\n     * const mongoCustomer: MongoDBCollectionConfig = {\n     *     slug: \"mongo_customer\",      // URL: /c/mongo_customer\n     *     path: \"customer\",            // MongoDB collection: customer\n     *     name: \"Customers (MongoDB)\",\n     *     engine: \"mongodb\",\n     *     properties: { ... }\n     * };\n     * ```\n     */\n    path?: string;\n}\n\n/**\n * A collection backed by any data source.\n * This is a discriminated union — use {@link PostgresCollectionConfig},\n * {@link FirebaseCollectionConfig}, or {@link MongoDBCollectionConfig} for\n * driver-specific type safety.\n *\n * @group Models\n */\nexport type CollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User> =\n    | PostgresCollectionConfig<M, USER>\n    | FirebaseCollectionConfig<M, USER>\n    | MongoDBCollectionConfig<M, USER>;\n\n/**\n * A collection of *any* row type.\n *\n * `CollectionConfig` is **invariant** in `M`: `callbacks` both consumes `M`\n * (`AfterReadProps<M>`) and produces it, so neither direction of assignment\n * holds. `CollectionConfig<SomeRow>` is therefore not assignable to a bare\n * `CollectionConfig`, whose `M` defaults to `Record<string, unknown>`.\n *\n * That matters wherever a collection is merely *referred to* rather than read\n * from. `defineCollection` returns a config whose `M` is inferred from the\n * properties — the whole point of it — so a field typed `() => CollectionConfig`\n * rejects every collection the builder produces, and `target: () => otherCollection`\n * (the documented way to point a relation at its other end) does not compile in\n * any project that uses the builder.\n *\n * `any` is deliberate and is what it is for here: these positions never read the\n * target's rows, they only identify which collection is meant, so there is no\n * type safety to preserve and invariance is pure obstruction.\n *\n * @group Models\n */\nexport type AnyCollectionConfig = CollectionConfig<any, any>;\n\n/**\n * Type guard for PostgreSQL collections.\n * Returns true if the collection uses the Postgres engine (or the default engine).\n *\n * Generic over the *input* type, and narrows by intersection rather than\n * replacement. Narrowing to a bare `PostgresCollectionConfig` discarded whatever\n * the caller actually had — most visibly the admin panel's view model, whose\n * flattened presentation fields vanished the moment a collection passed through\n * one of these guards.\n *\n * @group Models\n */\nexport function isPostgresCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & PostgresCollectionConfig<any, any> {\n    return !collection.engine || collection.engine === \"postgres\";\n}\n\n/**\n * Narrows to the SQL collection fields — `table`, `relations`,\n * `disableDefaultPolicies` — by asking the engine's declared capabilities\n * rather than by naming Postgres.\n *\n * The two halves of this already existed and were never joined. The engine\n * split (`PostgresCollectionConfig` / `FirebaseCollectionConfig` /\n * `MongoDBCollectionConfig`) said which fields belong to which engine at the\n * type level; {@link DataSourceCapabilities} said the same thing at runtime,\n * down to a `supportsRelations` flag. So call sites guarded on the capability\n * and then read a field the base type had to declare for them — which is why\n * those fields were on the base, and why a MongoDB collection could be written\n * with a `table`.\n *\n * Prefer this over {@link isPostgresCollectionConfig} wherever the question is\n * \"does this collection live in a SQL table\", so a custom SQL engine\n * registered through `registerDataSourceCapabilities` is included.\n *\n * @group Models\n */\nexport function isRelationalCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & PostgresCollectionConfig<any, any> {\n    return getDataSourceCapabilities(collection.engine).supportsRelations;\n}\n\n/**\n * Type guard for Firebase / Firestore collections.\n * @group Models\n */\nexport function isFirebaseCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & FirebaseCollectionConfig<any, any> {\n    return collection.engine === \"firestore\";\n}\n\n/**\n * Type guard for MongoDB collections.\n * @group Models\n */\nexport function isMongoDBCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & MongoDBCollectionConfig<any, any> {\n    return collection.engine === \"mongodb\";\n}\n\n/**\n * Returns the data path for a collection.\n * For Firestore or MongoDB collections with a `path`, returns that value;\n * otherwise falls back to `slug`.\n */\nexport function getCollectionDataPath<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>(\n    collection: CollectionConfig<M, USER>\n): string {\n    if (isFirebaseCollectionConfig(collection) && collection.path) {\n        return collection.path;\n    }\n    if (isMongoDBCollectionConfig(collection) && collection.path) {\n        return collection.path;\n    }\n    return collection.slug;\n}\n\n/**\n * Reads a collection's driver-declared subcollections thunk (the `subcollections`\n * field) independent of engine identity, so engine-agnostic code doesn't have to\n * type-guard against a specific driver. Returns `undefined` when the collection\n * declares none.\n *\n * Pair with `getDataSourceCapabilities(engine).supportsSubcollections` to decide\n * whether the engine honours subcollections at all before reading them.\n * @group Models\n */\nexport function getDeclaredSubcollections<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>(\n    collection: CollectionConfig<M, USER>\n): (() => CollectionConfig<Record<string, unknown>>[]) | undefined {\n    return (collection as FirebaseCollectionConfig<M, USER>).subcollections;\n}\n\n/**\n * Where the rows in an {@link EntityChildView} come from.\n *\n * The two are not the same thing, and conflating them is what made a Postgres\n * relation borrow Firestore's addressing:\n *\n * - `subcollection` is **containment**. The rows live under the parent; the\n *   path is their identity, and they cannot exist without it. This is what\n *   Firestore has natively.\n * - `relation` is a **link**. The rows are an ordinary collection, narrowed to\n *   those the parent reaches. `owned` means the child carries the parent's\n *   foreign key and belongs to it alone; `linked` means the row is shared\n *   through a junction, so what the parent controls is the link, not the row.\n *\n * @group Models\n */\nexport type ChildViewSource =\n    | { kind: \"subcollection\" }\n    | {\n        kind: \"relation\";\n        relationKey: string;\n        mode: \"owned\" | \"linked\";\n        /**\n         * Slug of the collection the rows actually live in.\n         *\n         * Distinct from the view's `key`, which is the relation. A `linked` view\n         * needs both: the key addresses the parent's set, and this addresses the\n         * whole collection to pick an existing row out of.\n         */\n        targetSlug: string;\n    };\n\n/**\n * A list of rows rendered inside an entity view — the tab under a record.\n *\n * This is a *presentation* descriptor, which is the whole point: rendering a\n * related list as a tab used to require minting a child `CollectionConfig` with\n * its own slug, which dragged a URL grammar, a path resolver and a second\n * read/write pipeline along with it. A tab needs a key, a collection to list,\n * and to know where its rows come from.\n *\n * @group Models\n */\nexport interface EntityChildView<M extends Record<string, unknown> = Record<string, unknown>> {\n    /**\n     * Stable identifier for this view: the tab id and the path segment.\n     *\n     * For a relation this is the **relation key** — the name the backend\n     * resolves a nested path segment by — not the target collection's slug.\n     * Those differ whenever a relation is named, which is every inline relation\n     * property, and the mismatch is why such a tab used to open onto an error.\n     */\n    key: string;\n\n    /** The collection whose rows this view lists, with any overrides applied. */\n    collection: CollectionConfig<M>;\n\n    source: ChildViewSource;\n}\n\n\nexport type { WhereFilterOp, FilterValues, WireFilterValues, FilterPreset } from \"./filter-operators\";\n\n\nexport type InferCollectionConfigType<S extends CollectionConfig> = S extends CollectionConfig<infer M> ? M : never;\n\n/**\n * Configuration for authentication collections.\n *\n * Controls what happens when admins create users, reset passwords,\n * and which entity actions are auto-injected.\n *\n * Use `auth: true` as sugar for `{ enabled: true }` with all defaults.\n *\n * @example Override user creation\n * ```ts\n * auth: {\n *     enabled: true,\n *     onCreateUser: async (values, ctx) => {\n *         const hash = await ctx.hashPassword(\"welcome123\");\n *         return {\n *             values: { ...values, passwordHash: hash, emailVerified: true },\n *             temporaryPassword: \"welcome123\",\n *         };\n *     },\n * }\n * ```\n *\n * @example Disable the reset-password entity action\n * ```ts\n * auth: {\n *     enabled: true,\n *     actions: { resetPassword: false },\n * }\n * ```\n *\n * @group Models\n */\nexport interface AuthCollectionConfig {\n    /** Set to true to mark this collection as the authentication collection. */\n    enabled: boolean;\n\n    /**\n     * Called when an admin creates a user via the collection REST API.\n     *\n     * Default: generate password → hash → normalize email → save →\n     *          send invitation email (or return temp password if no email configured).\n     *\n     * Override to implement custom invitation flows, LDAP sync, etc.\n     */\n    onCreateUser?: (\n        values: Record<string, unknown>,\n        ctx: AuthCollectionContext\n    ) => Promise<AuthCollectionCreateResult>;\n\n    /**\n     * Called when an admin resets a user's password via the admin panel.\n     *\n     * Default: generate reset token → send email (or generate + return temp password).\n     * Override for custom reset flows.\n     */\n    onResetPassword?: (\n        uid: string,\n        ctx: AuthCollectionContext\n    ) => Promise<AuthCollectionResetResult>;\n\n    /**\n     * Control which auth-specific entity actions are auto-injected.\n     *\n     * Default: `{ resetPassword: true }` — the framework auto-injects\n     * the built-in `resetPasswordAction` into the collection's entity actions.\n     *\n     * Set to `false` to disable, or pass a custom `EntityAction` to replace the UI.\n     *\n     * The object form is an `EntityAction` from `@rebasepro/admin-types`, typed\n     * here as `object` because it is a React component with admin controllers in\n     * its props and nothing on the server reads it — only whether the built-in\n     * action is injected, which is the boolean.\n     */\n    actions?: {\n        resetPassword?: boolean | object;\n    };\n}\n\n/**\n * Context provided to collection-level auth hooks.\n *\n * This is a simplified facade over the server internals —\n * it exposes only what's needed for custom auth flows without\n * coupling collection config to internal interfaces.\n *\n * @group Models\n */\nexport interface AuthCollectionContext {\n    /** Hash a password using the configured algorithm (scrypt by default). */\n    hashPassword: (password: string) => Promise<string>;\n    /** Send an email. Only available when email service is configured. */\n    sendEmail?: (options: { to: string; subject: string; html: string; text?: string }) => Promise<void>;\n    /** Whether the email service is configured and available. */\n    emailConfigured: boolean;\n    /** The app name from email config (for templates). */\n    appName: string;\n    /** The base URL for password reset links. */\n    resetPasswordUrl: string;\n}\n\n/**\n * Result of a collection-level `onCreateUser` hook.\n * @group Models\n */\nexport interface AuthCollectionCreateResult {\n    /** Processed values to persist (must include passwordHash, NOT raw password). */\n    values: Record<string, unknown>;\n    /** If set, shown to the admin in the creation result dialog. */\n    temporaryPassword?: string;\n    /** Whether an invitation email was sent. */\n    invitationSent?: boolean;\n}\n\n/**\n * Result of a collection-level `onResetPassword` hook.\n * @group Models\n */\nexport interface AuthCollectionResetResult {\n    /** If set, shown to the admin. */\n    temporaryPassword?: string;\n    /** Whether a reset email was sent. */\n    invitationSent?: boolean;\n}\n","/**\n * The SQL helper functions RLS policies call, and the schema they live in.\n *\n * ## One schema, and it is ours\n *\n * Rebase creates exactly one schema in a project's database: `rebase`. These\n * three functions live in it alongside the framework's own tables, and that is\n * the whole contract — a reader can look at a database and know precisely which\n * namespace belongs to the framework and that nothing else was touched.\n *\n * It used to be two. `uid()`, `jwt()` and `roles()` sat in a schema called\n * `auth`, which is Supabase's name, chosen so that a developer who had written\n * Supabase RLS would recognise `auth.uid()`. The familiarity was real but the\n * name was not Rebase's to take, and taking it had a concrete cost: pointing\n * Rebase at a database that already had a Supabase `auth` schema meant\n * `CREATE OR REPLACE FUNCTION auth.uid() RETURNS text` against Supabase's\n * `RETURNS uuid`, which Postgres rejects outright —\n *\n *     ERROR:  cannot change return type of existing function\n *     HINT:   Use DROP FUNCTION auth.uid() first.\n *\n * — and the failure landed inside a catch-all that logged a warning and carried\n * on, leaving a database with auth tables, no helper functions, and policies\n * calling functions that did not exist. Under `rebase db migrate` the same\n * statements aborted the migration instead.\n *\n * `rebase.uid()` collides with nobody. A Supabase database keeps its `auth`\n * schema untouched and gains a `rebase` one, which is what a gradual migration\n * needs.\n *\n * ## Why functions at all, rather than inlining `current_setting`\n *\n * Because the indirection has already been spent once. `uid()` resolves\n * `app.uid` and falls back to the pre-rename `app.user_id`, so that during a\n * rolling deploy — old and new pods serving one database — both eras resolve\n * the principal. That was a single `CREATE OR REPLACE`. Inlined into policy\n * bodies it would have been a rewrite of every policy on every table.\n *\n * ## Why the name is not configurable\n *\n * A policy body is stored SQL: Postgres parses `USING (…)` once and keeps it, so\n * these strings are written into every policy in every database Rebase has\n * provisioned. Everything that reads policies back — the SQL-to-policy parser\n * behind the admin UI, the drift checker, `rls-check` — would have to know the\n * configured value to recognise its own output. One frozen name is the feature.\n */\n\n/** The schema Rebase owns. The only schema Rebase creates. */\nexport const REBASE_SCHEMA = \"rebase\";\n\n/**\n * The principal of the current request, as text, or NULL in the server context.\n *\n * Never NULL for a user request — an anonymous one carries\n * {@link ANONYMOUS_USER_ID} — which is what makes `IS NULL` a reliable test for\n * the trusted server plane and `IS NOT NULL` a tautology.\n */\nexport const RLS_UID_SQL = `${REBASE_SCHEMA}.uid()`;\n\n/** The request's roles as a comma-separated string, for `string_to_array`. */\nexport const RLS_ROLES_SQL = `${REBASE_SCHEMA}.roles()`;\n\n/** The request's JWT claims as `jsonb`, or `{}`. */\nexport const RLS_JWT_SQL = `${REBASE_SCHEMA}.jwt()`;\n\n/**\n * The pre-1.0 spellings, for recognising policies and hand-written SQL that\n * predate the move.\n *\n * Kept because policies outlive the server that wrote them: a database migrated\n * by an older release still holds `auth.uid()` in its policy bodies until the\n * next push or boot recompiles them, and anything that reads policies back has\n * to recognise both eras or report the framework's own output as foreign drift.\n * Also used to give a project whose `securityRules` contain raw `auth.uid()` a\n * message naming the replacement, instead of a parse failure.\n */\nexport const LEGACY_RLS_SCHEMA = \"auth\";\nexport const LEGACY_RLS_UID_SQL = `${LEGACY_RLS_SCHEMA}.uid()`;\nexport const LEGACY_RLS_ROLES_SQL = `${LEGACY_RLS_SCHEMA}.roles()`;\nexport const LEGACY_RLS_JWT_SQL = `${LEGACY_RLS_SCHEMA}.jwt()`;\n\n/**\n * Rewrites the pre-1.0 function calls in a fragment of policy SQL.\n *\n * Deliberately anchored on a word boundary and the schema qualifier, so a column\n * called `auth_uid` or a table named `auth` is left alone.\n */\nexport function rewriteLegacyRlsFunctions(sql: string): string {\n    return sql.replace(\n        /\\bauth\\.(uid|jwt|roles)\\s*\\(\\s*\\)/gi,\n        (_match, fn: string) => `${REBASE_SCHEMA}.${fn.toLowerCase()}()`\n    );\n}\n\n/** Whether a fragment of SQL still calls the pre-1.0 functions. */\nexport function usesLegacyRlsFunctions(sql: string): boolean {\n    return /\\bauth\\.(uid|jwt|roles)\\s*\\(\\s*\\)/i.test(sql);\n}\n"],"mappings":";;;;;AAuJA,IAAM,kCAAkC;;;;;;;;;;;;;;;;;;;AAoBxC,SAAgB,4BAA4B,MAAqC;CAC7E,OAAO,GAAG,KAAK,IAAI,GAAG,KAAK,WAAW,KAAK,QAAQ,IAAI,KAAK,UAAU,GAAG;AAC7E;;;;;;;;;AAUA,SAAgB,2BAA2B,KAAgD;CACvF,MAAM,QAAQ,gCAAgC,KAAK,GAAG;CACtD,IAAI,CAAC,OAAO,OAAO,KAAA;CACnB,MAAM,GAAG,KAAK,UAAU,SAAS;CAKjC,IAAI,CAAC,SAAS,QAAQ,SAAS,OAAO,KAAA;CACtC,OAAO;EAAO;EAA4B;EAAU,GAAI,SAAS,EAAE,MAAM;CAAG;AAChF;;AAGA,SAAgB,wBAAwB,KAA4C;CAChF,OAAO,OAAO,QAAQ,YAAY,QAAQ,QACtC,OAAQ,IAA8B,aAAa,YACnD,OAAQ,IAA8B,QAAQ;AACtD;;AAGA,SAAgB,gBAAgB,KAAsB;CAClD,OAAO,wBAAwB,GAAG,IAAI,4BAA4B,GAAG,IAAI;AAC7E;;AAiJA,IAAa,oBAAmE;CAC5E,MAAM;CACN,MAAM;CACN,KAAK;CACL,MAAM;CACN,KAAK;CACL,MAAM;CACN,MAAM;CACN,UAAU;CACV,kBAAkB;CAClB,sBAAsB;CACtB,QAAQ;CACR,SAAS;CACT,YAAY;CACZ,aAAa;CACb,WAAW;CACX,eAAe;AACnB;;AAGA,IAAa,oBAAmE;CAC5E,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,QAAQ;CACR,SAAS;CACT,SAAS;CACT,UAAU;CACV,UAAU;CACV,WAAW;AACf;;;;;AAMA,IAAa,2BAAuC,IAAI,IAAmB,CACvE,WAAW,aACf,CAAC;;;;;;;AAQD,IAAa,uBAAiD;CAC1D;CAAK;CAAM;CAAM;CAAM;CAAM;CAC7B;CAAM;CACN;CAAkB;CAClB;CAAQ;CAAS;CAAY;CAC7B;CAAW;AACf;;AAGA,IAAM,gBAAqC,IAAI,IAAmB,oBAAoB;;;;;;;;;;;;;AActF,IAAM,iBAAqD,IAAI,IAC3D,OAAO,QAAQ,iBAAiB,CACpC;;;;;;;;;;;AAYA,SAAgB,cAAc,IAAuC;CACjE,IAAI,cAAc,IAAI,EAAE,GAAG,OAAO;CAClC,OAAO,eAAe,IAAI,EAAE;AAChC;;;;;;;;;AC9SA,IAAa,0BAA0B;;;;;;;;;;AAyFvC,IAAa,oCAAuD,CAAC,WAAW;;AAKhF,IAAa,wBAAgD;CACzD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CACjB,iBAAiB;CAGjB,yBAAyB;EAAC;EAAa;EAAc;EAAW;CAAQ;CACxE,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;;AAGA,IAAa,wBAAgD;CACzD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CAGjB,iBAAiB,qBAAqB,QAAO,OACzC,OAAO,UAAU,OAAO,WAAW,OAAO,cAAc,OAAO,WAAW;CAG9E,yBAAyB,CAAC;CAC1B,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;;AAGA,IAAa,uBAA+C;CACxD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CACjB,iBAAiB;CACjB,yBAAyB,CAAC;CAC1B,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;;;;;;AAOA,IAAa,uBAA+C;CACxD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CACjB,iBAAiB;CAKjB,yBAAyB;CAKzB,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;AAEA,IAAM,wBAAgE;CAClE,UAAU;CACV,WAAW;CACX,SAAS;CACT,aAAa;AACjB;;;;;;AAOA,SAAgB,0BAA0B,QAAyC;CAC/E,IAAI,CAAC,QAAQ,OAAO;CACpB,OAAO,sBAAsB,WAAW;AAC5C;;;;;;;;;;;;;;;ACmHA,SAAgB,2BACZ,YACoD;CACpD,OAAO,CAAC,WAAW,UAAU,WAAW,WAAW;AACvD;;;;;;;;;;;;;;;;;;;;;AAsBA,SAAgB,6BACZ,YACoD;CACpD,OAAO,0BAA0B,WAAW,MAAM,CAAC,CAAC;AACxD;;;;;AAMA,SAAgB,2BACZ,YACoD;CACpD,OAAO,WAAW,WAAW;AACjC;;;;;AAMA,SAAgB,0BACZ,YACmD;CACnD,OAAO,WAAW,WAAW;AACjC;;;;;;AAOA,SAAgB,sBACZ,YACM;CACN,IAAI,2BAA2B,UAAU,KAAK,WAAW,MACrD,OAAO,WAAW;CAEtB,IAAI,0BAA0B,UAAU,KAAK,WAAW,MACpD,OAAO,WAAW;CAEtB,OAAO,WAAW;AACtB;;;;;;;;;;;AAYA,SAAgB,0BACZ,YAC+D;CAC/D,OAAQ,WAAiD;AAC7D;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AClfA,IAAa,gBAAgB;;;;;;;;AAS7B,IAAa,cAAc,GAAG,cAAc;;AAG5C,IAAa,gBAAgB,GAAG,cAAc;;AAG9C,IAAa,cAAc,GAAG,cAAc;;;;;;;;;;;;AAa5C,IAAa,oBAAoB;AACC,GAAG,kBAAH;AACE,GAAG,kBAAH;AACF,GAAG,kBAAH"}
+{"version":3,"file":"src-CrCxd8km.js","names":[],"sources":["../../types/src/types/filter-operators.ts","../../types/src/types/data_source.ts","../../types/src/types/collections.ts","../../types/src/types/rls-functions.ts"],"sourcesContent":["/**\n * Canonical filter operators and REST wire-format mappings.\n *\n * `WhereFilterOp` is THE operator type used at every layer — from React\n * components through the SDK, server, and down to the database driver.\n *\n * PostgREST short-codes (`eq`, `gt`, `cs`, …) exist **only** at the\n * HTTP wire boundary, handled by `serializeFilter` / `deserializeFilter`\n * in `@rebasepro/common`.\n *\n * ┌──────────────────────┬───────────────┬──────────────────────────────┐\n * │ Canonical            │ REST short    │ Meaning                      │\n * ├──────────────────────┼───────────────┼──────────────────────────────┤\n * │ \"==\"                 │ \"eq\"          │ Equal                        │\n * │ \"!=\"                 │ \"neq\"         │ Not equal                    │\n * │ \">\"                  │ \"gt\"          │ Greater than                 │\n * │ \">=\"                 │ \"gte\"         │ Greater than or equal        │\n * │ \"<\"                  │ \"lt\"          │ Less than                    │\n * │ \"<=\"                 │ \"lte\"         │ Less than or equal           │\n * │ \"in\"                 │ \"in\"          │ Value in list                │\n * │ \"not-in\"             │ \"nin\"         │ Value not in list            │\n * │ \"array-contains\"     │ \"cs\"          │ Array contains element       │\n * │ \"array-contains-any\" │ \"csa\"         │ Array contains any of        │\n * │ \"like\"               │ \"like\"        │ SQL LIKE (case-sensitive)    │\n * │ \"ilike\"              │ \"ilike\"       │ SQL ILIKE (case-insensitive) │\n * │ \"not-like\"           │ \"nlike\"       │ NOT LIKE (case-sensitive)    │\n * │ \"not-ilike\"          │ \"nilike\"      │ NOT ILIKE (case-insensitive) │\n * │ \"is-null\"            │ \"isnull\"      │ Field IS NULL                │\n * │ \"is-not-null\"        │ \"notnull\"     │ Field IS NOT NULL            │\n * └──────────────────────┴───────────────┴──────────────────────────────┘\n *\n * Pattern matching (`like`/`ilike`) uses SQL wildcard syntax: `%` matches any\n * sequence of characters, `_` matches a single character. On MongoDB these are\n * translated to anchored regular expressions; Firestore has no native pattern\n * matching and rejects these operators (use `searchString` instead).\n *\n * @module\n */\n\n/**\n * Canonical sort representation: `[fieldName, direction]`.\n *\n * Used in `FindParams.orderBy`, `collection.sort`, and `FilterPreset.sort`.\n * The colon-string form (`\"field:direction\"`) exists only at the HTTP wire\n * boundary, handled by `serializeOrderBy` / `deserializeOrderBy` in\n * `@rebasepro/common`.\n *\n * @group Models\n */\nexport type OrderByTuple<Key extends string = string> = [Key, \"asc\" | \"desc\"];\n\n/**\n * One sort key, or several applied in order of significance.\n *\n * ```ts\n * orderBy: [\"created_at\", \"desc\"]                      // one key\n * orderBy: [[\"roles\", \"asc\"], [\"created_at\", \"desc\"]]  // roles, then newest first\n * ```\n *\n * The two forms are told apart by whether the first element is itself an\n * array, so a single tuple never needs wrapping and every existing caller\n * keeps working unchanged. `normalizeOrderBy` in `@rebasepro/common` collapses\n * both to the list form, which is what every layer below the call site speaks.\n *\n * Ties on the last key are broken by the row id, so a multi-key sort is a\n * total order and pages over it neither repeat nor skip rows.\n *\n * @group Models\n */\nexport type OrderBySpec<Key extends string = string> =\n    | OrderBySortTuple<Key>\n    | OrderBySortTuple<Key>[];\n\n/**\n * A sort key: a field name, or an aggregate over a to-many relation.\n *\n * @group Models\n */\nexport type SortKey<Key extends string = string> = Key | RelationAggregateSort;\n\n/**\n * `[sortKey, direction]` — the authoring form of {@link OrderByTuple}, which\n * additionally accepts a {@link RelationAggregateSort} object.\n *\n * The object never reaches a driver: `normalizeOrderBy` in `@rebasepro/common`\n * encodes it to its string spelling on the way down, and everything below that\n * point speaks plain `OrderByTuple`. See {@link RelationAggregateSort} for why\n * the wire form is a string.\n *\n * @group Models\n */\nexport type OrderBySortTuple<Key extends string = string> = [SortKey<Key>, \"asc\" | \"desc\"];\n\n/**\n * The aggregate functions a relation sort can apply.\n *\n * Five, and no `array_agg`/`string_agg`: an aggregate used as a sort key has to\n * produce something with an order, and these are the ones that do.\n *\n * @group Models\n */\nexport type RelationAggregateFn = \"min\" | \"max\" | \"count\" | \"sum\" | \"avg\";\n\n/**\n * Order rows by an aggregate over the rows a to-many relation reaches —\n * \"candidates, oldest waiting first\", \"clients, busiest first\".\n *\n * ```ts\n * // The date of each candidate's earliest open application.\n * orderBy: [[{ relation: \"applications\", field: \"created_at\", agg: \"min\" }, \"asc\"]]\n *\n * // How many applications each candidate has.\n * orderBy: [[{ relation: \"applications\", agg: \"count\" }, \"desc\"]]\n * ```\n *\n * This is the half of a queue that cannot be worked around client-side. A\n * *filter* over a relation can be approximated by denormalising a flag onto the\n * row; an *ordering* cannot be approximated at all once the result set is\n * paged, because the client only ever holds one page and the page was chosen by\n * the wrong order.\n *\n * Rows the relation reaches nothing from sort last ascending and first\n * descending — the placement Postgres gives a `NULL`, stated rather than\n * inherited, because the keyset comparison behind cursor paging has to agree\n * with it exactly. Ties are broken by the row id, so the order is total and\n * paging over it neither repeats nor skips.\n *\n * Compiled by the driver into a correlated subquery, so it is subject to the\n * reader's own row-level security on the target table: a related row the reader\n * cannot see does not contribute to the aggregate. Offered only where\n * {@link DataSourceCapabilities.relationAggregateSorts} says the driver can\n * compile it.\n *\n * @group Models\n */\nexport interface RelationAggregateSort {\n    /** The to-many relation to aggregate over, by its name on this collection. */\n    relation: string;\n\n    /** The aggregate to apply. */\n    agg: RelationAggregateFn;\n\n    /**\n     * The column of the *target* to aggregate. Required by every function\n     * except `count`, which counts the related rows themselves when it is\n     * omitted — and counts the rows whose column is non-null when it is not.\n     */\n    field?: string;\n}\n\n/** The wire spelling of a {@link RelationAggregateSort}: `min(applications.created_at)`. */\nconst RELATION_AGGREGATE_SORT_PATTERN = /^(min|max|count|sum|avg)\\(([^().]+)(?:\\.([^()]+))?\\)$/;\n\n/**\n * A {@link RelationAggregateSort} as a single string — `min(applications.created_at)`,\n * `count(applications)`.\n *\n * The wire form is a string because every layer below the call site already is\n * one: `OrderByTuple` is `[string, direction]`, the REST parameter is\n * `?orderBy=key:direction`, the driver contract takes `orderBy?: string |\n * OrderByTuple[]`, and a cursor names its keys by string. `_score` established\n * the same pattern — a sort key that is not a column, spelled as one — and this\n * reuses it rather than widening five signatures to carry an object that would\n * be flattened at the end anyway.\n *\n * SQL's own spelling, so the key reads as what it compiles to. Neither `:` nor\n * `,` appears in it, which is what keeps it safe in the colon-delimited wire\n * shorthand.\n *\n * @group Models\n */\nexport function encodeRelationAggregateSort(sort: RelationAggregateSort): string {\n    return `${sort.agg}(${sort.relation}${sort.field ? `.${sort.field}` : \"\"})`;\n}\n\n/**\n * Read the string spelling back, or `undefined` if it is not one.\n *\n * `undefined` rather than a throw: this is asked of *every* sort key to find\n * out which kind it is, and an ordinary column name is not an error.\n *\n * @group Models\n */\nexport function parseRelationAggregateSort(key: string): RelationAggregateSort | undefined {\n    const match = RELATION_AGGREGATE_SORT_PATTERN.exec(key);\n    if (!match) return undefined;\n    const [, agg, relation, field] = match;\n    // `min()` and friends have nothing to aggregate without a column, and a\n    // key that parses to a half-built sort would resolve to no expression and\n    // be dropped — leaving the rows unsorted while the caller believes\n    // otherwise. `count` is the one function that means something on its own.\n    if (!field && agg !== \"count\") return undefined;\n    return { agg: agg as RelationAggregateFn, relation, ...(field && { field }) };\n}\n\n/** Is this sort key the object form rather than a field name? */\nexport function isRelationAggregateSort(key: unknown): key is RelationAggregateSort {\n    return typeof key === \"object\" && key !== null &&\n        typeof (key as RelationAggregateSort).relation === \"string\" &&\n        typeof (key as RelationAggregateSort).agg === \"string\";\n}\n\n/** A sort key in the single-string form every layer below the call site speaks. */\nexport function sortKeyToString(key: SortKey): string {\n    return isRelationAggregateSort(key) ? encodeRelationAggregateSort(key) : key;\n}\n\n/**\n * Canonical filter operators supported across all database backends.\n * Each DB driver translates these to its native query format.\n *\n * @group Models\n */\nexport type WhereFilterOp =\n    | \"<\"\n    | \"<=\"\n    | \"==\"\n    | \"!=\"\n    | \">=\"\n    | \">\"\n    | \"array-contains\"\n    | \"in\"\n    | \"not-in\"\n    | \"array-contains-any\"\n    | \"like\"\n    | \"ilike\"\n    | \"not-like\"\n    | \"not-ilike\"\n    | \"is-null\"\n    | \"is-not-null\";\n\n/**\n * Used to define filters applied in collections.\n *\n * A single condition is a tuple `[operator, value]`.\n * Multiple conditions on the same field use an array of tuples.\n *\n * @example\n * // Single condition per field\n * { status: [\"==\", \"active\"], price: [\">=\", 9.99] }\n *\n * // Multiple conditions on one field\n * { age: [[\">=\", 18], [\"<\", 65]] }\n *\n * // Array operators\n * { role: [\"in\", [\"admin\", \"editor\"]] }\n * { tags: [\"array-contains\", \"featured\"] }\n *\n * // Pattern matching (SQL wildcards: % and _)\n * { name: [\"ilike\", \"%john%\"] }\n * { slug: [\"like\", \"post-%\"] }\n *\n * // Null checks (the value is ignored; `null` is conventional)\n * { deleted_at: [\"is-null\", null] }\n * { published_at: [\"is-not-null\", null] }\n *\n * @group Models\n */\nexport type FilterValues<Key extends string> =\n    Partial<Record<Key, [WhereFilterOp, unknown] | [WhereFilterOp, unknown][]>>;\n\n/**\n * The field names a query may address on a row type: every column, plus a\n * dotted path reaching inside one — or *through a relation* to a column of the\n * related row.\n *\n * A dotted path is not checked at all, in either direction. That is a\n * deliberate loosening, and it is worth being exact about what it costs. The\n * root used to be checked: `\"meta.tag\"` required a `meta` column. It cannot\n * stay checked, because the other thing a dotted path now means is\n * `\"applications.status\"` — and `applications` is a *relation*, which comes\n * from the collection's `relations` and is not a column of `M` at all. There is\n * nothing in a generated row type that could validate one. `FindParams.include`\n * is `string[]` for exactly this reason and says so.\n *\n * So the guarantee moves rather than disappears: an unresolvable path is a 400\n * from the driver, not a silently dropped condition. See\n * `UnknownFilterFieldsMode` in `@rebasepro/server-postgres` — dropping a filter\n * key *widens* the read to every row, which is why that resolution fails\n * closed. A typo'd relation path is refused at runtime with the target\n * collection's real column list in the message.\n *\n * Undotted keys are unaffected and still checked against `keyof M`.\n *\n * When `M` is left at its default `Record<string, unknown>`, `keyof M` is\n * `string` and this collapses to `string`, so every query stays permissive.\n * That is what keeps an untyped `createRebaseClient()` behaving exactly as it\n * did before the row type was threaded through.\n *\n * @group Models\n */\nexport type FieldPath<M extends Record<string, unknown> = Record<string, unknown>> =\n    | Extract<keyof M, string>\n    | `${string}.${string}`;\n\n/**\n * Relaxed filter type that also accepts pre-serialized PostgREST strings.\n * **Internal only** — used at the wire-format boundary\n * (`serializeFilter` / `deserializeFilter` in `@rebasepro/common`).\n *\n * Application code, UI components, and SDK consumers should use\n * {@link FilterValues} instead.\n *\n * @internal\n */\nexport type WireFilterValues<Key extends string> =\n    Partial<Record<Key, [WhereFilterOp, unknown] | [WhereFilterOp, unknown][] | string>>;\n\n/**\n * A pre-defined filter preset for quick access in the collection toolbar.\n * Users can select a preset to instantly apply a set of filters and\n * optionally a sort order.\n *\n * @group Models\n */\nexport interface FilterPreset<Key extends string = string> {\n    /**\n     * Display label shown in the preset menu.\n     * If omitted, a summary is auto-generated from the filter keys.\n     */\n    label?: string;\n\n    /**\n     * The filter values to apply when this preset is selected.\n     */\n    filterValues: FilterValues<Key>;\n\n    /**\n     * Optional sort override to apply alongside the filter values.\n     * One key, or several in order of significance.\n     */\n    sort?: OrderBySpec<Key>;\n}\n\n/**\n * PostgREST short-code operators. Wire format only — these never appear\n * in application code. Used by `serializeFilter`/`deserializeFilter`\n * in `@rebasepro/common`.\n */\nexport type RestFilterOp =\n    | \"eq\" | \"neq\"\n    | \"gt\" | \"gte\"\n    | \"lt\" | \"lte\"\n    | \"in\" | \"nin\"\n    | \"cs\" | \"csa\"\n    | \"like\" | \"ilike\"\n    | \"nlike\" | \"nilike\"\n    | \"isnull\" | \"notnull\";\n\n/** Maps canonical operators to their REST short-code equivalents. */\nexport const CANONICAL_TO_REST: Readonly<Record<WhereFilterOp, RestFilterOp>> = {\n    \"==\": \"eq\",\n    \"!=\": \"neq\",\n    \">\": \"gt\",\n    \">=\": \"gte\",\n    \"<\": \"lt\",\n    \"<=\": \"lte\",\n    \"in\": \"in\",\n    \"not-in\": \"nin\",\n    \"array-contains\": \"cs\",\n    \"array-contains-any\": \"csa\",\n    \"like\": \"like\",\n    \"ilike\": \"ilike\",\n    \"not-like\": \"nlike\",\n    \"not-ilike\": \"nilike\",\n    \"is-null\": \"isnull\",\n    \"is-not-null\": \"notnull\"\n};\n\n/** Maps REST short-code operators to their canonical equivalents. */\nexport const REST_TO_CANONICAL: Readonly<Record<RestFilterOp, WhereFilterOp>> = {\n    \"eq\": \"==\",\n    \"neq\": \"!=\",\n    \"gt\": \">\",\n    \"gte\": \">=\",\n    \"lt\": \"<\",\n    \"lte\": \"<=\",\n    \"in\": \"in\",\n    \"nin\": \"not-in\",\n    \"cs\": \"array-contains\",\n    \"csa\": \"array-contains-any\",\n    \"like\": \"like\",\n    \"ilike\": \"ilike\",\n    \"nlike\": \"not-like\",\n    \"nilike\": \"not-ilike\",\n    \"isnull\": \"is-null\",\n    \"notnull\": \"is-not-null\"\n};\n\n/**\n * Operators that test for null/not-null and therefore ignore their value.\n * Codecs normalize the value of these conditions to `null`.\n */\nexport const NULL_OPS: ReadonlySet<WhereFilterOp> = new Set<WhereFilterOp>([\n    \"is-null\", \"is-not-null\"\n]);\n\n/**\n * Every canonical operator, in a stable order. Useful for engine capability\n * declarations ({@link DataSourceCapabilities.filterOperators}) and for\n * building operator subsets.\n * @group Models\n */\nexport const ALL_WHERE_FILTER_OPS: readonly WhereFilterOp[] = [\n    \"<\", \"<=\", \"==\", \"!=\", \">=\", \">\",\n    \"in\", \"not-in\",\n    \"array-contains\", \"array-contains-any\",\n    \"like\", \"ilike\", \"not-like\", \"not-ilike\",\n    \"is-null\", \"is-not-null\"\n];\n\n/** All canonical operator strings for runtime validation. */\nconst CANONICAL_OPS: ReadonlySet<string> = new Set<WhereFilterOp>(ALL_WHERE_FILTER_OPS);\n\n/**\n * The REST table as a `Map`, because the key `toCanonicalOp` is handed comes\n * off the wire.\n *\n * Indexed as a plain object, every `Object.prototype` member answered:\n * `toCanonicalOp(\"valueOf\")` returned the inherited *function* as though it\n * were a `WhereFilterOp`, and every caller here treats a defined result as\n * \"known operator\". Same defect the REST codec's own lookup tables were\n * converted away from in `filter-dialect.ts`; this is the copy that survived\n * one package over, and it now sits under the operator validation the REST\n * parser does, which would otherwise have admitted `[\"constructor\", x]`.\n */\nconst REST_OP_LOOKUP: ReadonlyMap<string, WhereFilterOp> = new Map<string, WhereFilterOp>(\n    Object.entries(REST_TO_CANONICAL) as [string, WhereFilterOp][]\n);\n\n/**\n * Resolve any operator string (canonical or REST short-code) to its\n * canonical `WhereFilterOp` form. Returns `undefined` for unknown operators.\n *\n * @example\n * toCanonicalOp(\"==\")   // \"==\"\n * toCanonicalOp(\"eq\")   // \"==\"\n * toCanonicalOp(\"cs\")   // \"array-contains\"\n * toCanonicalOp(\"xyz\")  // undefined\n */\nexport function toCanonicalOp(op: string): WhereFilterOp | undefined {\n    if (CANONICAL_OPS.has(op)) return op as WhereFilterOp;\n    return REST_OP_LOOKUP.get(op);\n}\n","import { ALL_WHERE_FILTER_OPS, WhereFilterOp } from \"./filter-operators\";\n\n/**\n * Describes the capabilities and features supported by a data source (driver).\n *\n * Each driver (Postgres, Firebase, MongoDB, etc.) declares which features it\n * supports. The admin uses this descriptor to:\n * - Show/hide editor tabs (e.g. Relations for SQL, Subcollections for Firebase)\n * - Filter the property type picker (e.g. `relation` for SQL, `reference` for Firebase)\n * - Toggle driver-specific form controls (e.g. `columnType` for SQL)\n *\n * @group Models\n */\nexport interface DataSourceCapabilities {\n    /** Unique driver key (e.g. \"postgres\", \"firestore\", \"mongodb\") */\n    key: string;\n\n    /** Human-readable label for the UI (e.g. \"PostgreSQL\", \"Firebase / Firestore\") */\n    label: string;\n\n    // ── Feature flags ─────────────────────────────────────────────────\n    /** Does this source support SQL-style relations (JOINs)? */\n    supportsRelations: boolean;\n\n    /** Does this source support nested subcollections? */\n    supportsSubcollections: boolean;\n\n    /** Does this source support Row Level Security policies? */\n    supportsRLS: boolean;\n\n    /** Does this source support document references (Firebase-style)? */\n    supportsReferences: boolean;\n\n    /** Does this source support SQL column type annotations? */\n    supportsColumnTypes: boolean;\n\n    /** Does this source support real-time listeners? */\n    supportsRealtime: boolean;\n\n    /**\n     * Does this source store vectors natively?\n     *\n     * `VectorProperty` carries a `dimensions` and is pgvector-shaped. It was\n     * the one driver-specific property kind with no flag to gate it, so unlike\n     * every other field in this descriptor there was not even a runtime answer\n     * to appeal to — a Firestore collection could declare an embedding column\n     * and no driver would do anything with it.\n     */\n    supportsVectors: boolean;\n\n    /**\n     * Canonical filter operators this engine can execute.\n     *\n     * The admin UI intersects this set with the property-type defaults and\n     * any per-property narrowing (`property.ui.filterOperators`) to decide\n     * which operators to offer in filter fields — so an engine that cannot\n     * run `ilike` (e.g. Firestore) never shows a \"Contains\" filter that\n     * would throw at query time.\n     */\n    filterOperators: readonly WhereFilterOp[];\n\n    /**\n     * Relation kinds this engine's driver can compile into a filter.\n     *\n     * Only `belongsTo` puts a column on the row being filtered; the others are\n     * answered with a correlated subquery over the junction or the target\n     * table, which not every driver can build. An engine with no relations at\n     * all declares none.\n     *\n     * The admin uses this to decide whether a relation column offers a filter\n     * control. Offering one an engine cannot answer is not cosmetic: a driver\n     * that drops the key it cannot resolve *widens* the read to every row, and\n     * one that fails closed answers a control the admin itself put on screen\n     * with a 400.\n     *\n     * Optional, so a third-party driver registered before this existed still\n     * compiles. Omitted means {@link DEFAULT_FILTERABLE_RELATION_KINDS} — the\n     * one kind that is a plain column comparison, which every relational\n     * driver can do. The subquery kinds are a real capability and have to be\n     * claimed rather than assumed: assuming them wrongly is the widening.\n     */\n    filterableRelationKinds?: readonly string[];\n\n    /**\n     * Can a filter address a *column of the related row* — `applications.status`\n     * — rather than only the related row's id?\n     *\n     * A separate capability from {@link filterableRelationKinds} because it is\n     * a separate subquery: the id filter stops at the junction, one of these\n     * reaches the target table and compares one of its columns. A driver can\n     * do the first and not the second.\n     *\n     * Optional and defaulting to **false**, for the reason the relation kinds\n     * default narrow: an unclaimed capability that the admin assumes is there\n     * produces a control whose query the driver answers by dropping the key —\n     * and a dropped filter key widens the read to every row.\n     *\n     * Meaningless without {@link supportsRelations}; a driver with no relations\n     * has nothing to reach through.\n     */\n    supportsRelationFieldFilters?: boolean;\n\n    /**\n     * Can a sort key be an aggregate over a to-many relation — \"oldest waiting\n     * first\", \"busiest first\"?\n     *\n     * Compiled as a correlated scalar subquery in `ORDER BY`, which a document\n     * store cannot express at all. Optional and defaulting to **false**.\n     *\n     * A wrongly claimed sort capability fails differently from a wrongly\n     * claimed filter one, and worse in one respect: a driver that cannot\n     * resolve the key drops the `ORDER BY` and answers 200 with rows in\n     * whatever order the database pleased, which reads as a sorted list. Paging\n     * over that repeats and skips rows.\n     */\n    relationAggregateSorts?: boolean;\n\n    // ── Admin capability flags ───────────────────────────────────────\n    /** Does this source support SQL admin operations (SQL editor, EXPLAIN, etc.)? */\n    supportsSQLAdmin: boolean;\n\n    /** Does this source support document admin operations (aggregation, stats)? */\n    supportsDocumentAdmin: boolean;\n\n    /** Does this source support schema admin (unmapped tables, table metadata)? */\n    supportsSchemaAdmin: boolean;\n}\n\n/**\n * Subset of DataSourceCapabilities containing only feature flags.\n * Useful when you only need to check capabilities without UI metadata.\n * @group Models\n */\nexport type DataSourceFeatures = Omit<DataSourceCapabilities, \"key\" | \"label\">;\n\n/**\n * The default data-source key, used when a collection does not name a\n * `dataSource`. Shared by the frontend router and the backend driver\n * registry so both agree on \"the default database\".\n * @group Models\n */\nexport const DEFAULT_DATA_SOURCE_KEY = \"(default)\";\n\n/**\n * How the *frontend* reaches a data source.\n *\n * - `\"server\"` — through the Rebase backend (the `RebaseClient`). The backend\n *   holds the actual database adapter and routes by data-source key. This is\n *   the default and covers Postgres, MongoDB, and any other server-mediated\n *   engine.\n * - `\"direct\"` — straight from the client to the external backend via its own\n *   SDK driver (e.g. Firestore). The Rebase backend is not in the data path.\n * - `\"custom\"` — a developer-supplied {@link DataDriver}, transport unspecified.\n *\n * @group Models\n */\nexport type DataSourceTransport = \"server\" | \"direct\" | \"custom\";\n\n/**\n * Declarative definition of a data source — a named place data lives.\n *\n * Declared once and shared front and back: the frontend uses it to decide\n * transport (client vs direct driver), the backend uses the same `key` to\n * resolve a database adapter, and the editor derives capabilities from\n * `engine`. Collections reference a definition by its `key` via\n * `collection.dataSource`.\n *\n * @group Models\n */\nexport interface DataSourceDefinition {\n    /**\n     * Unique identifier for this data source. Collections point at it via\n     * `dataSource`. Defaults to {@link DEFAULT_DATA_SOURCE_KEY}.\n     */\n    key: string;\n\n    /**\n     * The engine backing this data source (e.g. `\"postgres\"`, `\"mongodb\"`,\n     * `\"firestore\"`, or a custom id). Determines the\n     * {@link DataSourceCapabilities} surfaced in the editor.\n     */\n    engine: string;\n\n    /**\n     * How the frontend reaches this source. Optional — when omitted it is\n     * inferred: `\"direct\"` if the definition carries a client-side driver,\n     * `\"server\"` otherwise.\n     */\n    transport?: DataSourceTransport;\n\n    /**\n     * The physical database/schema/Firestore-database within the engine.\n     * Threaded to drivers/adapters as the existing `databaseId` runtime\n     * parameter. Defaults to the engine's own default.\n     */\n    databaseId?: string;\n\n    /** Human-readable label for the UI. */\n    label?: string;\n}\n\n/**\n * The resolved data source for a collection: the single source of truth that\n * the frontend router, backend registry, and editor all derive from.\n * Produced by `resolveDataSource(collection, registry)`.\n *\n * @group Models\n */\nexport interface ResolvedDataSource {\n    /** Data-source key (routing key, shared front + back). */\n    key: string;\n    /** Engine backing the source (drives capabilities). */\n    engine: string;\n    /** Frontend transport. */\n    transport: DataSourceTransport;\n    /** Within-engine instance, if any (the `databaseId` runtime param). */\n    databaseId?: string;\n    /** Capabilities derived from {@link engine}. */\n    capabilities: DataSourceCapabilities;\n}\n\n/**\n * Relation kinds assumed filterable when a driver does not say.\n *\n * `belongsTo` alone: its filter is a comparison on a column of the row being\n * filtered, the one shape that needs no query construction a driver might not\n * have. Everything else is a correlated subquery over another table.\n *\n * @group Models\n */\nexport const DEFAULT_FILTERABLE_RELATION_KINDS: readonly string[] = [\"belongsTo\"];\n\n// ── Built-in driver capabilities ─────────────────────────────────────\n\n/** @group Models */\nexport const POSTGRES_CAPABILITIES: DataSourceCapabilities = {\n    key: \"postgres\",\n    label: \"PostgreSQL\",\n    supportsRelations: true,\n    supportsSubcollections: false,\n    supportsRLS: true,\n    supportsReferences: false,\n    supportsColumnTypes: true,\n    supportsRealtime: true,\n    supportsVectors: true,\n    filterOperators: ALL_WHERE_FILTER_OPS,\n    // `via` is absent: its join path is authored source → target with no\n    // stated inverse, so the driver has nothing to reverse into a filter.\n    filterableRelationKinds: [\"belongsTo\", \"manyToMany\", \"hasMany\", \"hasOne\"],\n    supportsRelationFieldFilters: true,\n    relationAggregateSorts: true,\n    supportsSQLAdmin: true,\n    supportsDocumentAdmin: false,\n    supportsSchemaAdmin: true\n};\n\n/** @group Models */\nexport const FIREBASE_CAPABILITIES: DataSourceCapabilities = {\n    key: \"firestore\",\n    label: \"Firebase / Firestore\",\n    supportsRelations: false,\n    supportsSubcollections: true,\n    supportsRLS: false,\n    supportsReferences: true,\n    supportsColumnTypes: false,\n    supportsRealtime: true,\n    supportsVectors: false,\n    // Firestore has no SQL pattern matching — the driver throws on the LIKE\n    // family, so the UI must never offer it.\n    filterOperators: ALL_WHERE_FILTER_OPS.filter(op =>\n        op !== \"like\" && op !== \"ilike\" && op !== \"not-like\" && op !== \"not-ilike\"),\n    // No relations at all — a document store links by reference. Nothing to\n    // reach through, so neither of the two relation-reaching features either.\n    filterableRelationKinds: [],\n    supportsRelationFieldFilters: false,\n    relationAggregateSorts: false,\n    supportsSQLAdmin: false,\n    supportsDocumentAdmin: false,\n    supportsSchemaAdmin: false\n};\n\n/** @group Models */\nexport const MONGODB_CAPABILITIES: DataSourceCapabilities = {\n    key: \"mongodb\",\n    label: \"MongoDB\",\n    supportsRelations: false,\n    supportsSubcollections: true,\n    supportsRLS: false,\n    supportsReferences: true,\n    supportsColumnTypes: false,\n    supportsRealtime: false,\n    supportsVectors: false,\n    filterOperators: ALL_WHERE_FILTER_OPS,\n    filterableRelationKinds: [],\n    supportsRelationFieldFilters: false,\n    relationAggregateSorts: false,\n    supportsSQLAdmin: false,\n    supportsDocumentAdmin: true,\n    supportsSchemaAdmin: true\n};\n\n/**\n * Fallback capabilities when the driver is unknown.\n * Enables everything so nothing is hidden unexpectedly.\n * @group Models\n */\nexport const DEFAULT_CAPABILITIES: DataSourceCapabilities = {\n    key: \"(default)\",\n    label: \"Default\",\n    supportsRelations: true,\n    supportsSubcollections: true,\n    supportsRLS: true,\n    supportsReferences: true,\n    supportsColumnTypes: true,\n    supportsRealtime: true,\n    supportsVectors: true,\n    filterOperators: ALL_WHERE_FILTER_OPS,\n    // The exception to this descriptor's \"enable everything\" rule. The other\n    // flags hide a tab or a picker when they are wrong; this one decides\n    // whether a query is sent that an unknown driver may answer by dropping\n    // the condition — which returns every row rather than none.\n    filterableRelationKinds: DEFAULT_FILTERABLE_RELATION_KINDS,\n    // Narrow for the same reason, and more sharply. An unknown driver that is\n    // assumed to compile these answers by dropping the key: the filter widens\n    // the read to every row, and the sort comes back unordered while looking\n    // sorted. Both have to be claimed.\n    supportsRelationFieldFilters: false,\n    relationAggregateSorts: false,\n    supportsSQLAdmin: true,\n    supportsDocumentAdmin: true,\n    supportsSchemaAdmin: true\n};\n\nconst CAPABILITIES_REGISTRY: Record<string, DataSourceCapabilities> = {\n    postgres: POSTGRES_CAPABILITIES,\n    firestore: FIREBASE_CAPABILITIES,\n    mongodb: MONGODB_CAPABILITIES,\n    \"(default)\": DEFAULT_CAPABILITIES\n};\n\n/**\n * Look up capabilities for a given engine key.\n * If `engine` is undefined or not found, returns `DEFAULT_CAPABILITIES`.\n * @group Models\n */\nexport function getDataSourceCapabilities(engine?: string): DataSourceCapabilities {\n    if (!engine) return POSTGRES_CAPABILITIES; // postgres is the default engine\n    return CAPABILITIES_REGISTRY[engine] ?? DEFAULT_CAPABILITIES;\n}\n\n/**\n * Register custom capabilities for a third-party driver.\n * @group Models\n */\nexport function registerDataSourceCapabilities(capabilities: DataSourceCapabilities): void {\n    CAPABILITIES_REGISTRY[capabilities.key] = capabilities;\n}\n","import type { CollectionCallbacks } from \"./entity_callbacks\";\n\nimport type { EnumValues, Properties, PostgresProperties, FirebaseProperties, MongoProperties } from \"./properties\";\n\nimport type { User } from \"../users\";\nimport type { Relation } from \"./relations\";\nimport type { SecurityRule } from \"./security_rules\";\nimport { getDataSourceCapabilities } from \"./data_source\";\nimport type { WhereFilterOp, FilterValues, FilterPreset } from \"./filter-operators\";\nimport type { SearchConfig } from \"./search\";\n\n/**\n * Base interface containing all driver-agnostic collection properties.\n * Use {@link PostgresCollectionConfig} or {@link FirebaseCollectionConfig} for\n * driver-specific type safety, or {@link CollectionConfig} when you\n * need to handle any collection regardless of backend.\n *\n * @group Models\n */\nexport interface BaseCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User> {\n\n    /**\n     * The collection's identity. Required, and the value nearly everything else\n     * keys on:\n     *\n     * - the REST path — `/api/data/<slug>`\n     * - the SDK accessor — `client.data.<slug>` / `client.data.collection(\"<slug>\")`\n     * - the admin panel's URL\n     * - the target of a `reference` or `relation` property\n     *\n     * Conventionally kebab-case and plural (`blog-posts`). It is independent of\n     * {@link table}: the slug is what callers say, the table is where the rows\n     * live, and renaming one does not rename the other.\n     *\n     * Treat it as frozen once anything has shipped against it — changing a slug\n     * changes every URL and every generated accessor at once.\n     *\n     * @example\n     * defineCollection({\n     *     slug: \"blog-posts\",   // /api/data/blog-posts, client.data.blogPosts\n     *     table: \"posts\",\n     *     properties: { … }\n     * })\n     */\n    slug: string;\n\n    /**\n     * Name of the collection, typically plural.\n     * E.g. `Products`, `Blog`\n     */\n    name: string;\n\n    /**\n     * Singular name of an entry in this collection\n     * E.g. `Product`, `Blog entry`\n     */\n    singularName?: string;\n\n    /**\n     * Optional description of this view. You can use Markdown.\n     */\n    description?: string;\n\n    /**\n     * Child collections nested under entities of this collection.\n     * Populated automatically during normalization from driver-specific fields\n     * (e.g. Firebase `subcollections`, Postgres `relations` with many-cardinality).\n     *\n     * Custom drivers can set this directly to expose child collections to the UI.\n     */\n    childCollections?: () => CollectionConfig<Record<string, unknown>>[];\n\n\n    /**\n     * The data source this collection belongs to — the routing key shared by\n     * the frontend router and the backend driver registry. It points at a\n     * {@link DataSourceDefinition} registered on `<Rebase dataSources>` (front)\n     * and `initializeRebaseBackend({ dataSources })` (back).\n     *\n     * If not specified, the default data source `\"(default)\"` is used, which\n     * for a standard Rebase app is the server-mediated Postgres backend.\n     *\n     * @example\n     * // Default data source (server-mediated Postgres)\n     * { slug: \"products\" }\n     *\n     * // A direct-transport Firestore data source registered as \"analytics\"\n     * { slug: \"events\", dataSource: \"analytics\" }\n     */\n    dataSource?: string;\n\n    /**\n     * The database engine backing this collection (`\"postgres\"`, `\"firestore\"`,\n     * `\"mongodb\"`, or a custom id).\n     *\n     * On concrete collection types ({@link PostgresCollectionConfig},\n     * {@link FirebaseCollectionConfig}, {@link MongoDBCollectionConfig}) this is a literal\n     * discriminant. On the base type it is optional and gets stamped\n     * automatically during collection normalization from the registered\n     * {@link DataSourceDefinition}.\n     *\n     * Prefer setting {@link dataSource} and letting the engine be resolved.\n     */\n    engine?: string;\n\n    /**\n     * Which database within the engine.\n     * - For Firestore: The Firestore database ID (e.g., for multi-database projects)\n     * - For PostgreSQL: Schema or database name\n     * - For MongoDB: Database name\n     *\n     * If not specified, the default database of the engine is used. Resolved\n     * from the collection's {@link DataSourceDefinition} when omitted here.\n     */\n    databaseId?: string;\n\n    /**\n     * Set of properties that compose a entity\n     */\n    properties: Properties;\n\n\n\n\n\n\n\n\n\n\n\n\n    /**\n     * Mark this collection as an authentication collection.\n     * When true, this collection is used for user management, login, password hashing, and invitation flows.\n     */\n    auth?: boolean | AuthCollectionConfig;\n\n\n\n\n\n\n\n    /**\n     * Row-level authorization rules for this collection.\n     *\n     * Driver-agnostic on purpose, unlike `disableDefaultPolicies`, `table` and\n     * `relations`, which are declared on {@link PostgresCollectionConfig} only.\n     * The rules are a *contract* — who may read or write which rows — and each\n     * engine enforces it its own way:\n     *\n     * - **Postgres** compiles them to real `CREATE POLICY` statements and lets\n     *   the database enforce them (see {@link PostgresCollectionConfig.securityRules},\n     *   which narrows this with the raw-SQL details).\n     * - **MongoDB** translates them into a query filter it AND-s into every\n     *   read and write, honouring `access`, `ownerField`, `roles`, `mode` and\n     *   the `operation`/`operations` selectors, and making a best effort at raw\n     *   `using`/`withCheck` SQL.\n     * - **Firestore** does not implement them at all; its own rules language is\n     *   evaluated by Google, not from here. `supportsRLS` on\n     *   {@link DataSourceCapabilities} reports which engines generate policies,\n     *   which is not the same question as whether an engine honours a rule.\n     */\n    securityRules?: readonly SecurityRule[];\n\n    /**\n     * This interface defines all the callbacks that can be used when a entity\n     * is being created, updated or deleted.\n     * Useful for adding your own logic or blocking the execution of the operation.\n     */\n    readonly callbacks?: CollectionCallbacks<M, USER>;\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n    /**\n     * User id of the owner of this collection. This is used only by plugins, or if you\n     * are writing custom code\n     */\n    ownerId?: string;\n\n    /**\n     * Arbitrary key-value metadata for external consumers.\n     * Not interpreted by Rebase — passed through serialization unchanged.\n     * Used by domain apps to store custom per-collection config.\n     */\n    metadata?: Record<string, unknown>;\n\n\n\n\n    /**\n     * If set to true, changes to the entity will be saved in a subcollection.\n     * This prop has no effect if the history plugin is not enabled\n     */\n    history?: boolean;\n\n    /**\n     * Whether a write naming a field this collection does not declare is\n     * rejected with a 400. Defaults to `true`.\n     *\n     * Set to `false` where a column really does exist that the config never\n     * declared — populated by a trigger, or introspected rather than declared —\n     * and callers need to write it. The column still has to exist: the driver\n     * checks the key against the table's own columns whatever this is set to,\n     * because a key with no column behind it is not passed to the database and\n     * refused, it is dropped from the statement and answered 201.\n     *\n     * It does not let a typo through to Postgres for Postgres to judge. That is\n     * what this flag was documented as doing, and no such judgment ever\n     * happened.\n     */\n    strictWrites?: boolean;\n\n\n\n\n\n\n\n\n}\n\n// ── Driver-specific collection types ──────────────────────────────────\n\n/**\n * A collection backed by PostgreSQL (or any SQL database).\n * Adds support for SQL-style relations (JOINs) and Row Level Security.\n *\n * Use this type instead of {@link CollectionConfig} when you want\n * compile-time safety that only SQL-relevant fields appear.\n *\n * @group Models\n */\nexport interface PostgresCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>\n    extends BaseCollectionConfig<M, USER> {\n    properties: PostgresProperties;\n\n    /**\n     * The database engine for this collection. For Postgres collections this\n     * can be omitted (Postgres is the default) or set to `\"postgres\"`.\n     */\n    engine?: \"postgres\" | undefined;\n\n    /**\n     * The PostgreSQL table name for this collection.\n     */\n    table: string;\n\n    /**\n     * The PostgreSQL schema name for this table.\n     * E.g. \"public\", \"rebase\", \"auth\".\n     * If not specified, \"public\" is used (or the default search path).\n     */\n    schema?: string;\n\n    /**\n     * For SQL databases, you can define the relations between collections here.\n     * Relations describe JOINs, foreign keys, and junction tables.\n     */\n    relations?: Relation[];\n\n    /**\n     * Security rules for this collection (PostgreSQL Row Level Security).\n     * When defined, the schema generator will enable RLS on the table and\n     * create the corresponding PostgreSQL policies.\n     *\n     * Supports three levels of expressiveness:\n     * 1. **Convenience shortcuts** — `ownerField`, `access`, `roles`\n     * 2. **Raw SQL** — `using` and `withCheck` for full PostgreSQL power\n     * 3. **Combined** — mix shortcuts with `roles` for common patterns\n     *\n     * The authenticated user context is available in raw SQL via:\n     * - `rebase.uid()`   — the current user's ID\n     * - `rebase.roles()` — comma-separated app role IDs\n     * - `rebase.jwt()`   — full JWT claims as JSONB\n     */\n    securityRules?: readonly SecurityRule[];\n\n    /**\n     * Opt out of the framework's default Row Level Security policies.\n     *\n     * The schema generator automatically injects, for every collection, a\n     * baseline SELECT policy granting the trusted server context and the\n     * `admin` role read access (reads run under a restricted role, so RLS\n     * default-denies without it). For auth collections it additionally injects\n     * a self-read policy (`id = rebase.uid()`) and an admin-only write gate\n     * (INSERT/UPDATE/DELETE require the `admin` role or the trusted server\n     * context), making privileged columns such as `roles` safe by default.\n     *\n     * Author-defined `securityRules` are permissive and broaden access on top\n     * of these defaults. Set this flag to `true` to remove the defaults\n     * entirely and take full responsibility for the collection's RLS.\n     *\n     * @default false\n     */\n    disableDefaultPolicies?: boolean;\n\n    /**\n     * Opt in to Postgres full-text search for this collection.\n     *\n     * Omit it and `.search()` keeps its existing behaviour exactly — an\n     * `ILIKE '%term%'` across top-level string properties. Declare it and the\n     * collection gains one generated `tsvector` column and a GIN index, and\n     * `.search()` compiles to a ranked `@@ websearch_to_tsquery` against them.\n     *\n     * Postgres-only, like {@link VectorProperty}: the block is rejected at boot\n     * on other engines rather than silently ignored.\n     *\n     * @see SearchConfig\n     */\n    search?: SearchConfig;\n}\n\n/**\n * A collection backed by Firebase / Firestore.\n * Adds support for subcollections (nested document collections).\n *\n * Use this type instead of {@link CollectionConfig} when you want\n * compile-time safety that only Firestore-relevant fields appear.\n *\n * @group Models\n */\nexport interface FirebaseCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>\n    extends BaseCollectionConfig<M, USER> {\n    /**\n     * The database engine for this collection. Must be set to `\"firestore\"`.\n     */\n    engine: \"firestore\";\n\n    /**\n     * Set of properties that compose a entity.\n     * Firestore collections support `reference` properties but not `relation`.\n     */\n    properties: FirebaseProperties;\n\n    /**\n     * The Firestore collection path to query. Defaults to `slug` if not set.\n     * Use this when the Firestore path differs from the slug\n     * (e.g., when a PostgreSQL collection already uses the same slug).\n     *\n     * @example\n     * ```typescript\n     * const fsCustomer: FirebaseCollectionConfig = {\n     *     slug: \"fs_customer\",        // URL: /c/fs_customer\n     *     path: \"customer\",           // Firestore path: customer\n     *     name: \"Customers (Firestore)\",\n     *     engine: \"firestore\",\n     *     properties: { ... }\n     * };\n     * ```\n     */\n    path?: string;\n\n    /**\n     * You can add subcollections to your entity in the same way you define the root\n     * collections. The collections added here will be displayed when opening\n     * the side dialog of a entity.\n     */\n    subcollections?: () => CollectionConfig<Record<string, unknown>>[];\n}\n\n/**\n * A collection backed by MongoDB.\n *\n * Use this type instead of {@link CollectionConfig} when you want\n * compile-time safety that only MongoDB-relevant fields appear.\n *\n * @group Models\n */\nexport interface MongoDBCollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>\n    extends BaseCollectionConfig<M, USER> {\n\n    /**\n     * The database engine for this collection. Must be set to `\"mongodb\"`.\n     */\n    engine: \"mongodb\";\n\n    /**\n     * Set of properties that compose a entity.\n     * MongoDB collections support `reference` properties but not `relation`.\n     */\n    properties: MongoProperties;\n\n    /**\n     * The MongoDB collection name to use. Defaults to `slug` if not set.\n     * Use this when the MongoDB collection name differs from the slug\n     * (e.g., when a PostgreSQL collection already uses the same slug).\n     *\n     * @example\n     * ```typescript\n     * const mongoCustomer: MongoDBCollectionConfig = {\n     *     slug: \"mongo_customer\",      // URL: /c/mongo_customer\n     *     path: \"customer\",            // MongoDB collection: customer\n     *     name: \"Customers (MongoDB)\",\n     *     engine: \"mongodb\",\n     *     properties: { ... }\n     * };\n     * ```\n     */\n    path?: string;\n}\n\n/**\n * A collection backed by any data source.\n * This is a discriminated union — use {@link PostgresCollectionConfig},\n * {@link FirebaseCollectionConfig}, or {@link MongoDBCollectionConfig} for\n * driver-specific type safety.\n *\n * @group Models\n */\nexport type CollectionConfig<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User> =\n    | PostgresCollectionConfig<M, USER>\n    | FirebaseCollectionConfig<M, USER>\n    | MongoDBCollectionConfig<M, USER>;\n\n/**\n * A collection of *any* row type.\n *\n * `CollectionConfig` is **invariant** in `M`: `callbacks` both consumes `M`\n * (`AfterReadProps<M>`) and produces it, so neither direction of assignment\n * holds. `CollectionConfig<SomeRow>` is therefore not assignable to a bare\n * `CollectionConfig`, whose `M` defaults to `Record<string, unknown>`.\n *\n * That matters wherever a collection is merely *referred to* rather than read\n * from. `defineCollection` returns a config whose `M` is inferred from the\n * properties — the whole point of it — so a field typed `() => CollectionConfig`\n * rejects every collection the builder produces, and `target: () => otherCollection`\n * (the documented way to point a relation at its other end) does not compile in\n * any project that uses the builder.\n *\n * `any` is deliberate and is what it is for here: these positions never read the\n * target's rows, they only identify which collection is meant, so there is no\n * type safety to preserve and invariance is pure obstruction.\n *\n * @group Models\n */\nexport type AnyCollectionConfig = CollectionConfig<any, any>;\n\n/**\n * Type guard for PostgreSQL collections.\n * Returns true if the collection uses the Postgres engine (or the default engine).\n *\n * Generic over the *input* type, and narrows by intersection rather than\n * replacement. Narrowing to a bare `PostgresCollectionConfig` discarded whatever\n * the caller actually had — most visibly the admin panel's view model, whose\n * flattened presentation fields vanished the moment a collection passed through\n * one of these guards.\n *\n * @group Models\n */\nexport function isPostgresCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & PostgresCollectionConfig<any, any> {\n    return !collection.engine || collection.engine === \"postgres\";\n}\n\n/**\n * Narrows to the SQL collection fields — `table`, `relations`,\n * `disableDefaultPolicies` — by asking the engine's declared capabilities\n * rather than by naming Postgres.\n *\n * The two halves of this already existed and were never joined. The engine\n * split (`PostgresCollectionConfig` / `FirebaseCollectionConfig` /\n * `MongoDBCollectionConfig`) said which fields belong to which engine at the\n * type level; {@link DataSourceCapabilities} said the same thing at runtime,\n * down to a `supportsRelations` flag. So call sites guarded on the capability\n * and then read a field the base type had to declare for them — which is why\n * those fields were on the base, and why a MongoDB collection could be written\n * with a `table`.\n *\n * Prefer this over {@link isPostgresCollectionConfig} wherever the question is\n * \"does this collection live in a SQL table\", so a custom SQL engine\n * registered through `registerDataSourceCapabilities` is included.\n *\n * @group Models\n */\nexport function isRelationalCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & PostgresCollectionConfig<any, any> {\n    return getDataSourceCapabilities(collection.engine).supportsRelations;\n}\n\n/**\n * Type guard for Firebase / Firestore collections.\n * @group Models\n */\nexport function isFirebaseCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & FirebaseCollectionConfig<any, any> {\n    return collection.engine === \"firestore\";\n}\n\n/**\n * Type guard for MongoDB collections.\n * @group Models\n */\nexport function isMongoDBCollectionConfig<C extends CollectionConfig<any, any>>(\n    collection: C\n): collection is C & MongoDBCollectionConfig<any, any> {\n    return collection.engine === \"mongodb\";\n}\n\n/**\n * Returns the data path for a collection.\n * For Firestore or MongoDB collections with a `path`, returns that value;\n * otherwise falls back to `slug`.\n */\nexport function getCollectionDataPath<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>(\n    collection: CollectionConfig<M, USER>\n): string {\n    if (isFirebaseCollectionConfig(collection) && collection.path) {\n        return collection.path;\n    }\n    if (isMongoDBCollectionConfig(collection) && collection.path) {\n        return collection.path;\n    }\n    return collection.slug;\n}\n\n/**\n * Reads a collection's driver-declared subcollections thunk (the `subcollections`\n * field) independent of engine identity, so engine-agnostic code doesn't have to\n * type-guard against a specific driver. Returns `undefined` when the collection\n * declares none.\n *\n * Pair with `getDataSourceCapabilities(engine).supportsSubcollections` to decide\n * whether the engine honours subcollections at all before reading them.\n * @group Models\n */\nexport function getDeclaredSubcollections<M extends Record<string, unknown> = Record<string, unknown>, USER extends User = User>(\n    collection: CollectionConfig<M, USER>\n): (() => CollectionConfig<Record<string, unknown>>[]) | undefined {\n    return (collection as FirebaseCollectionConfig<M, USER>).subcollections;\n}\n\n/**\n * Where the rows in an {@link EntityChildView} come from.\n *\n * The two are not the same thing, and conflating them is what made a Postgres\n * relation borrow Firestore's addressing:\n *\n * - `subcollection` is **containment**. The rows live under the parent; the\n *   path is their identity, and they cannot exist without it. This is what\n *   Firestore has natively.\n * - `relation` is a **link**. The rows are an ordinary collection, narrowed to\n *   those the parent reaches. `owned` means the child carries the parent's\n *   foreign key and belongs to it alone; `linked` means the row is shared\n *   through a junction, so what the parent controls is the link, not the row.\n *\n * @group Models\n */\nexport type ChildViewSource =\n    | { kind: \"subcollection\" }\n    | {\n        kind: \"relation\";\n        relationKey: string;\n        mode: \"owned\" | \"linked\";\n        /**\n         * Slug of the collection the rows actually live in.\n         *\n         * Distinct from the view's `key`, which is the relation. A `linked` view\n         * needs both: the key addresses the parent's set, and this addresses the\n         * whole collection to pick an existing row out of.\n         */\n        targetSlug: string;\n    };\n\n/**\n * A list of rows rendered inside an entity view — the tab under a record.\n *\n * This is a *presentation* descriptor, which is the whole point: rendering a\n * related list as a tab used to require minting a child `CollectionConfig` with\n * its own slug, which dragged a URL grammar, a path resolver and a second\n * read/write pipeline along with it. A tab needs a key, a collection to list,\n * and to know where its rows come from.\n *\n * @group Models\n */\nexport interface EntityChildView<M extends Record<string, unknown> = Record<string, unknown>> {\n    /**\n     * Stable identifier for this view: the tab id and the path segment.\n     *\n     * For a relation this is the **relation key** — the name the backend\n     * resolves a nested path segment by — not the target collection's slug.\n     * Those differ whenever a relation is named, which is every inline relation\n     * property, and the mismatch is why such a tab used to open onto an error.\n     */\n    key: string;\n\n    /** The collection whose rows this view lists, with any overrides applied. */\n    collection: CollectionConfig<M>;\n\n    source: ChildViewSource;\n}\n\n\nexport type { WhereFilterOp, FilterValues, WireFilterValues, FilterPreset } from \"./filter-operators\";\n\n\nexport type InferCollectionConfigType<S extends CollectionConfig> = S extends CollectionConfig<infer M> ? M : never;\n\n/**\n * Configuration for authentication collections.\n *\n * Controls what happens when admins create users, reset passwords,\n * and which entity actions are auto-injected.\n *\n * Use `auth: true` as sugar for `{ enabled: true }` with all defaults.\n *\n * @example Override user creation\n * ```ts\n * auth: {\n *     enabled: true,\n *     onCreateUser: async (values, ctx) => {\n *         const hash = await ctx.hashPassword(\"welcome123\");\n *         return {\n *             values: { ...values, passwordHash: hash, emailVerified: true },\n *             temporaryPassword: \"welcome123\",\n *         };\n *     },\n * }\n * ```\n *\n * @example Disable the reset-password entity action\n * ```ts\n * auth: {\n *     enabled: true,\n *     actions: { resetPassword: false },\n * }\n * ```\n *\n * @group Models\n */\nexport interface AuthCollectionConfig {\n    /** Set to true to mark this collection as the authentication collection. */\n    enabled: boolean;\n\n    /**\n     * Called when an admin creates a user via the collection REST API.\n     *\n     * Default: generate password → hash → normalize email → save →\n     *          send invitation email (or return temp password if no email configured).\n     *\n     * Override to implement custom invitation flows, LDAP sync, etc.\n     */\n    onCreateUser?: (\n        values: Record<string, unknown>,\n        ctx: AuthCollectionContext\n    ) => Promise<AuthCollectionCreateResult>;\n\n    /**\n     * Called when an admin resets a user's password via the admin panel.\n     *\n     * Default: generate reset token → send email (or generate + return temp password).\n     * Override for custom reset flows.\n     */\n    onResetPassword?: (\n        uid: string,\n        ctx: AuthCollectionContext\n    ) => Promise<AuthCollectionResetResult>;\n\n    /**\n     * Control which auth-specific entity actions are auto-injected.\n     *\n     * Default: `{ resetPassword: true }` — the framework auto-injects\n     * the built-in `resetPasswordAction` into the collection's entity actions.\n     *\n     * Set to `false` to disable, or pass a custom `EntityAction` to replace the UI.\n     *\n     * The object form is an `EntityAction` from `@rebasepro/admin-types`, typed\n     * here as `object` because it is a React component with admin controllers in\n     * its props and nothing on the server reads it — only whether the built-in\n     * action is injected, which is the boolean.\n     */\n    actions?: {\n        resetPassword?: boolean | object;\n    };\n}\n\n/**\n * Context provided to collection-level auth hooks.\n *\n * This is a simplified facade over the server internals —\n * it exposes only what's needed for custom auth flows without\n * coupling collection config to internal interfaces.\n *\n * @group Models\n */\nexport interface AuthCollectionContext {\n    /** Hash a password using the configured algorithm (scrypt by default). */\n    hashPassword: (password: string) => Promise<string>;\n    /** Send an email. Only available when email service is configured. */\n    sendEmail?: (options: { to: string; subject: string; html: string; text?: string }) => Promise<void>;\n    /** Whether the email service is configured and available. */\n    emailConfigured: boolean;\n    /** The app name from email config (for templates). */\n    appName: string;\n    /** The base URL for password reset links. */\n    resetPasswordUrl: string;\n}\n\n/**\n * Result of a collection-level `onCreateUser` hook.\n * @group Models\n */\nexport interface AuthCollectionCreateResult {\n    /** Processed values to persist (must include passwordHash, NOT raw password). */\n    values: Record<string, unknown>;\n    /** If set, shown to the admin in the creation result dialog. */\n    temporaryPassword?: string;\n    /** Whether an invitation email was sent. */\n    invitationSent?: boolean;\n}\n\n/**\n * Result of a collection-level `onResetPassword` hook.\n * @group Models\n */\nexport interface AuthCollectionResetResult {\n    /** If set, shown to the admin. */\n    temporaryPassword?: string;\n    /** Whether a reset email was sent. */\n    invitationSent?: boolean;\n}\n","/**\n * The SQL helper functions RLS policies call, and the schema they live in.\n *\n * ## One schema, and it is ours\n *\n * Rebase creates exactly one schema in a project's database: `rebase`. These\n * three functions live in it alongside the framework's own tables, and that is\n * the whole contract — a reader can look at a database and know precisely which\n * namespace belongs to the framework and that nothing else was touched.\n *\n * It used to be two. `uid()`, `jwt()` and `roles()` sat in a schema called\n * `auth`, which is Supabase's name, chosen so that a developer who had written\n * Supabase RLS would recognise `auth.uid()`. The familiarity was real but the\n * name was not Rebase's to take, and taking it had a concrete cost: pointing\n * Rebase at a database that already had a Supabase `auth` schema meant\n * `CREATE OR REPLACE FUNCTION auth.uid() RETURNS text` against Supabase's\n * `RETURNS uuid`, which Postgres rejects outright —\n *\n *     ERROR:  cannot change return type of existing function\n *     HINT:   Use DROP FUNCTION auth.uid() first.\n *\n * — and the failure landed inside a catch-all that logged a warning and carried\n * on, leaving a database with auth tables, no helper functions, and policies\n * calling functions that did not exist. Under `rebase db migrate` the same\n * statements aborted the migration instead.\n *\n * `rebase.uid()` collides with nobody. A Supabase database keeps its `auth`\n * schema untouched and gains a `rebase` one, which is what a gradual migration\n * needs.\n *\n * ## Why functions at all, rather than inlining `current_setting`\n *\n * Because the indirection has already been spent once. `uid()` resolves\n * `app.uid` and falls back to the pre-rename `app.user_id`, so that during a\n * rolling deploy — old and new pods serving one database — both eras resolve\n * the principal. That was a single `CREATE OR REPLACE`. Inlined into policy\n * bodies it would have been a rewrite of every policy on every table.\n *\n * ## Why the name is not configurable\n *\n * A policy body is stored SQL: Postgres parses `USING (…)` once and keeps it, so\n * these strings are written into every policy in every database Rebase has\n * provisioned. Everything that reads policies back — the SQL-to-policy parser\n * behind the admin UI, the drift checker, `rls-check` — would have to know the\n * configured value to recognise its own output. One frozen name is the feature.\n */\n\n/** The schema Rebase owns. The only schema Rebase creates. */\nexport const REBASE_SCHEMA = \"rebase\";\n\n/**\n * The principal of the current request, as text, or NULL in the server context.\n *\n * Never NULL for a user request — an anonymous one carries\n * {@link ANONYMOUS_USER_ID} — which is what makes `IS NULL` a reliable test for\n * the trusted server plane and `IS NOT NULL` a tautology.\n */\nexport const RLS_UID_SQL = `${REBASE_SCHEMA}.uid()`;\n\n/** The request's roles as a comma-separated string, for `string_to_array`. */\nexport const RLS_ROLES_SQL = `${REBASE_SCHEMA}.roles()`;\n\n/** The request's JWT claims as `jsonb`, or `{}`. */\nexport const RLS_JWT_SQL = `${REBASE_SCHEMA}.jwt()`;\n\n/**\n * The pre-1.0 spellings, for recognising policies and hand-written SQL that\n * predate the move.\n *\n * Kept because policies outlive the server that wrote them: a database migrated\n * by an older release still holds `auth.uid()` in its policy bodies until the\n * next push or boot recompiles them, and anything that reads policies back has\n * to recognise both eras or report the framework's own output as foreign drift.\n * Also used to give a project whose `securityRules` contain raw `auth.uid()` a\n * message naming the replacement, instead of a parse failure.\n */\nexport const LEGACY_RLS_SCHEMA = \"auth\";\nexport const LEGACY_RLS_UID_SQL = `${LEGACY_RLS_SCHEMA}.uid()`;\nexport const LEGACY_RLS_ROLES_SQL = `${LEGACY_RLS_SCHEMA}.roles()`;\nexport const LEGACY_RLS_JWT_SQL = `${LEGACY_RLS_SCHEMA}.jwt()`;\n\n/**\n * Rewrites the pre-1.0 function calls in a fragment of policy SQL.\n *\n * Deliberately anchored on a word boundary and the schema qualifier, so a column\n * called `auth_uid` or a table named `auth` is left alone.\n */\nexport function rewriteLegacyRlsFunctions(sql: string): string {\n    return sql.replace(\n        /\\bauth\\.(uid|jwt|roles)\\s*\\(\\s*\\)/gi,\n        (_match, fn: string) => `${REBASE_SCHEMA}.${fn.toLowerCase()}()`\n    );\n}\n\n/** Whether a fragment of SQL still calls the pre-1.0 functions. */\nexport function usesLegacyRlsFunctions(sql: string): boolean {\n    return /\\bauth\\.(uid|jwt|roles)\\s*\\(\\s*\\)/i.test(sql);\n}\n"],"mappings":";;;;;AAuJA,IAAM,kCAAkC;;;;;;;;;;;;;;;;;;;AAoBxC,SAAgB,4BAA4B,MAAqC;CAC7E,OAAO,GAAG,KAAK,IAAI,GAAG,KAAK,WAAW,KAAK,QAAQ,IAAI,KAAK,UAAU,GAAG;AAC7E;;;;;;;;;AAUA,SAAgB,2BAA2B,KAAgD;CACvF,MAAM,QAAQ,gCAAgC,KAAK,GAAG;CACtD,IAAI,CAAC,OAAO,OAAO,KAAA;CACnB,MAAM,GAAG,KAAK,UAAU,SAAS;CAKjC,IAAI,CAAC,SAAS,QAAQ,SAAS,OAAO,KAAA;CACtC,OAAO;EAAO;EAA4B;EAAU,GAAI,SAAS,EAAE,MAAM;CAAG;AAChF;;AAGA,SAAgB,wBAAwB,KAA4C;CAChF,OAAO,OAAO,QAAQ,YAAY,QAAQ,QACtC,OAAQ,IAA8B,aAAa,YACnD,OAAQ,IAA8B,QAAQ;AACtD;;AAGA,SAAgB,gBAAgB,KAAsB;CAClD,OAAO,wBAAwB,GAAG,IAAI,4BAA4B,GAAG,IAAI;AAC7E;;AAiJA,IAAa,oBAAmE;CAC5E,MAAM;CACN,MAAM;CACN,KAAK;CACL,MAAM;CACN,KAAK;CACL,MAAM;CACN,MAAM;CACN,UAAU;CACV,kBAAkB;CAClB,sBAAsB;CACtB,QAAQ;CACR,SAAS;CACT,YAAY;CACZ,aAAa;CACb,WAAW;CACX,eAAe;AACnB;;AAGA,IAAa,oBAAmE;CAC5E,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,MAAM;CACN,OAAO;CACP,QAAQ;CACR,SAAS;CACT,SAAS;CACT,UAAU;CACV,UAAU;CACV,WAAW;AACf;;;;;AAMA,IAAa,2BAAuC,IAAI,IAAmB,CACvE,WAAW,aACf,CAAC;;;;;;;AAQD,IAAa,uBAAiD;CAC1D;CAAK;CAAM;CAAM;CAAM;CAAM;CAC7B;CAAM;CACN;CAAkB;CAClB;CAAQ;CAAS;CAAY;CAC7B;CAAW;AACf;;AAGA,IAAM,gBAAqC,IAAI,IAAmB,oBAAoB;;;;;;;;;;;;;AActF,IAAM,iBAAqD,IAAI,IAC3D,OAAO,QAAQ,iBAAiB,CACpC;;;;;;;;;;;AAYA,SAAgB,cAAc,IAAuC;CACjE,IAAI,cAAc,IAAI,EAAE,GAAG,OAAO;CAClC,OAAO,eAAe,IAAI,EAAE;AAChC;;;;;;;;;AC9SA,IAAa,0BAA0B;;;;;;;;;;AAyFvC,IAAa,oCAAuD,CAAC,WAAW;;AAKhF,IAAa,wBAAgD;CACzD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CACjB,iBAAiB;CAGjB,yBAAyB;EAAC;EAAa;EAAc;EAAW;CAAQ;CACxE,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;;AAGA,IAAa,wBAAgD;CACzD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CAGjB,iBAAiB,qBAAqB,QAAO,OACzC,OAAO,UAAU,OAAO,WAAW,OAAO,cAAc,OAAO,WAAW;CAG9E,yBAAyB,CAAC;CAC1B,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;;AAGA,IAAa,uBAA+C;CACxD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CACjB,iBAAiB;CACjB,yBAAyB,CAAC;CAC1B,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;;;;;;AAOA,IAAa,uBAA+C;CACxD,KAAK;CACL,OAAO;CACP,mBAAmB;CACnB,wBAAwB;CACxB,aAAa;CACb,oBAAoB;CACpB,qBAAqB;CACrB,kBAAkB;CAClB,iBAAiB;CACjB,iBAAiB;CAKjB,yBAAyB;CAKzB,8BAA8B;CAC9B,wBAAwB;CACxB,kBAAkB;CAClB,uBAAuB;CACvB,qBAAqB;AACzB;AAEA,IAAM,wBAAgE;CAClE,UAAU;CACV,WAAW;CACX,SAAS;CACT,aAAa;AACjB;;;;;;AAOA,SAAgB,0BAA0B,QAAyC;CAC/E,IAAI,CAAC,QAAQ,OAAO;CACpB,OAAO,sBAAsB,WAAW;AAC5C;;;;;;;;;;;;;;;ACmHA,SAAgB,2BACZ,YACoD;CACpD,OAAO,CAAC,WAAW,UAAU,WAAW,WAAW;AACvD;;;;;;;;;;;;;;;;;;;;;AAsBA,SAAgB,6BACZ,YACoD;CACpD,OAAO,0BAA0B,WAAW,MAAM,CAAC,CAAC;AACxD;;;;;AAMA,SAAgB,2BACZ,YACoD;CACpD,OAAO,WAAW,WAAW;AACjC;;;;;AAMA,SAAgB,0BACZ,YACmD;CACnD,OAAO,WAAW,WAAW;AACjC;;;;;;AAOA,SAAgB,sBACZ,YACM;CACN,IAAI,2BAA2B,UAAU,KAAK,WAAW,MACrD,OAAO,WAAW;CAEtB,IAAI,0BAA0B,UAAU,KAAK,WAAW,MACpD,OAAO,WAAW;CAEtB,OAAO,WAAW;AACtB;;;;;;;;;;;AAYA,SAAgB,0BACZ,YAC+D;CAC/D,OAAQ,WAAiD;AAC7D;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AClfA,IAAa,gBAAgB;;;;;;;;AAS7B,IAAa,cAAc,GAAG,cAAc;;AAG5C,IAAa,gBAAgB,GAAG,cAAc;;AAG9C,IAAa,cAAc,GAAG,cAAc;;;;;;;;;;;;AAa5C,IAAa,oBAAoB;AACC,GAAG,kBAAH;AACE,GAAG,kBAAH;AACF,GAAG,kBAAH"}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rebasepro/server",
   "type": "module",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Database-Agnostic Backend Core for Rebase",
   "funding": {
     "url": "https://github.com/sponsors/rebaseco"
@@ -44,10 +44,10 @@
     "jsonwebtoken": "^9.0.3",
     "ws": "^8.21.1",
     "zod": "^4.4.3",
-    "@rebasepro/client": "0.15.0",
-    "@rebasepro/types": "0.15.0",
-    "@rebasepro/common": "0.15.0",
-    "@rebasepro/utils": "0.15.0"
+    "@rebasepro/client": "0.16.0",
+    "@rebasepro/types": "0.16.0",
+    "@rebasepro/common": "0.16.0",
+    "@rebasepro/utils": "0.16.0"
   },
   "devDependencies": {
     "@jest/globals": "^30.4.1",