@rebasepro/server-postgres 0.11.1-canary.gfd39654 → 0.12.1-canary.g06f263c

package/dist/schema/ensure-collection-policies.d.ts

@@ -0,0 +1,60 @@
+/**
+ * Applying a bundle's RLS policies to a database at boot, idempotently.
+ *
+ * ## Why this exists
+ *
+ * {@link ensureCollectionTables} creates the collection *tables* a managed
+ * runtime boots against, but a table with row-level security disabled and no
+ * policies is not servable: authenticated requests run as the restricted
+ * `rebase_user` role, so a read with no `SELECT` policy returns nothing (a
+ * public collection answered 401) and a write with no `INSERT`/`UPDATE` policy
+ * is denied. The policies live in the collections' `securityRules`; nothing at
+ * boot applied them. `rebase db push` does — but it drives Atlas against a
+ * local `DATABASE_URL`, and a managed tenant's database is reachable only from
+ * inside the cluster, by the runtime that is already connected to it. So the
+ * runtime is the only thing that *can* apply them, and this is where it does.
+ *
+ * ## Why this is safe to run on every boot
+ *
+ * Every statement is idempotent: `ENABLE ROW LEVEL SECURITY` is a no-op once
+ * enabled, and each policy is a `DROP POLICY IF EXISTS` immediately followed by
+ * a `CREATE POLICY`, so re-applying asserts exactly the declared state. It adds
+ * and replaces; it never drops data. (It does not *reconcile* — a policy a
+ * previous push left behind under an old name is not removed here; that stays a
+ * `db push` / `db migrate` concern, alongside destructive schema changes.)
+ *
+ * Unlike table creation, a failure here is not fatal: RLS stays enabled, so a
+ * table whose policies could not be applied fails **closed** (denies) rather
+ * than leaking rows. One collection's policy failing (e.g. a rule that
+ * references a table a real migration has not created yet) must not crash-loop
+ * the whole deployment and take the other collections' working routes down with
+ * it. Failures are reported loudly and per-table so the operator can see
+ * exactly which collection is not yet servable and why.
+ */
+import { type CollectionConfig } from "@rebasepro/types";
+import { type Queryable } from "./ensure-collection-tables";
+export interface PolicyEnsureResult {
+    /** `CREATE POLICY` statements that ran successfully. */
+    policiesApplied: number;
+    /** Tables that had RLS enabled. */
+    tablesSecured: number;
+    /** Declared tables absent from the database — left to a real migration. */
+    skipped: {
+        table: string;
+        reason: string;
+    }[];
+    /** Tables whose RLS could not be fully applied (fail closed). */
+    failures: {
+        table: string;
+        error: string;
+    }[];
+}
+/**
+ * Bring the declared collections' RLS policies up to date. Returns what it did.
+ *
+ * Only tables that already exist are touched: the boot-time table creator runs
+ * first, so anything still missing is a table this additive path is not allowed
+ * to create (a junction, or a relation left to a migration). Enabling RLS on a
+ * non-existent table would error, so those are recorded as skipped, not failed.
+ */
+export declare function ensureCollectionPolicies(client: Queryable, collections: CollectionConfig[], log?: (message: string) => void): Promise<PolicyEnsureResult>;

package/dist/schema/ensure-collection-tables.d.ts

@@ -46,9 +46,17 @@ export interface ExistingSchema {
     tables: Map<string, Set<string>>;
     /** `schema.typename` of every enum type that already exists. */
     enums: Set<string>;
+    /**
+     * `schema.table.constraint` of every constraint that already exists.
+     *
+     * Optional so a caller that only cares about tables can still build one by
+     * hand; absent is read as "none known", which at worst re-attempts a
+     * constraint that then fails harmlessly as a duplicate.
+     */
+    constraints?: Set<string>;
 }
 export interface EnsureAction {
-    kind: "create-enum" | "create-table" | "add-column";
+    kind: "create-enum" | "create-table" | "add-column" | "add-constraint";
     /** Qualified target, for logging: `public.posts` or `public.posts.title`. */
     target: string;
     sql: string;
@@ -58,6 +66,20 @@ export interface EnsurePlan {
     /** Every statement, in dependency order. Empty when the schema is current. */
     statements: string[];
 }
+export interface EnsureOutcome extends EnsurePlan {
+    /**
+     * Constraints that could not be added — always non-fatal.
+     *
+     * A foreign key can only fail on data that already violates it, and the
+     * column it would police exists either way, so the collection still serves.
+     * Refusing to boot over one would turn a pre-existing data problem into an
+     * outage. Reported loudly instead.
+     */
+    failures: {
+        target: string;
+        error: string;
+    }[];
+}
 /**
  * Decide what to add. Pure — the caller supplies what exists and runs the result.
  *
@@ -76,4 +98,4 @@ export declare function readExistingSchema(client: Queryable, schemas: string[])
  * cannot be added, say) should not roll back the tables that were created fine.
  * The error is surfaced with the statement that caused it.
  */
-export declare function ensureCollectionTables(client: Queryable, collections: CollectionConfig[], log?: (message: string) => void): Promise<EnsurePlan>;
+export declare function ensureCollectionTables(client: Queryable, collections: CollectionConfig[], log?: (message: string) => void): Promise<EnsureOutcome>;

package/dist/schema/generate-postgres-ddl-logic.d.ts

@@ -1,8 +1,123 @@
-import { CollectionConfig, Property } from "@rebasepro/types";
+import { CollectionConfig, Property, SecurityRule } from "@rebasepro/types";
 export declare const resolveColumnName: (propName: string, prop?: Property | null) => string;
+export declare const getPrimaryKeyProp: (collection: CollectionConfig) => {
+    name: string;
+    type: "string" | "number";
+    isUuid: boolean;
+};
+export declare const isNumericId: (collection: CollectionConfig) => boolean;
+export declare const getPrimaryKeyName: (collection: CollectionConfig) => string;
 export declare const isIdProperty: (propName: string, prop: Property, collection: CollectionConfig) => boolean;
+type ResolveCollection = (slug: string) => CollectionConfig | undefined;
+/**
+ * The individual SQL statements a single security rule compiles to: a
+ * `DROP POLICY IF EXISTS` / `CREATE POLICY` pair per operation, each a complete
+ * statement (terminated by `;`, no trailing newline).
+ *
+ * This is the primitive the boot-time RLS applier runs one statement at a time
+ * (the runtime's DB handle speaks the extended query protocol, which forbids
+ * multiple commands in one execute), while `db push` writes the joined string.
+ */
+export declare const generatePolicyStatements: (collection: CollectionConfig, rule: SecurityRule, resolveCollection: ResolveCollection) => string[];
 export declare const getSqlColumnType: (propName: string, prop: Property, collection: CollectionConfig, collections: CollectionConfig[]) => string;
 export declare const generatePostgresDdl: (collections: CollectionConfig[], options?: {
     includePolicies?: boolean;
 }) => Promise<string>;
+/** The RLS statements one declared collection's table needs, ready to run. */
+/**
+ * A foreign key, as both its parts and the statement that creates it.
+ *
+ * `ALTER TABLE … ADD CONSTRAINT` has no `IF NOT EXISTS`, so a caller applying
+ * these has to skip by name — hence the name is a field and not only a substring
+ * of the SQL.
+ */
+export interface ForeignKeyPlan {
+    constraintName: string;
+    schema: string;
+    /** Bare table name, no schema prefix. */
+    table: string;
+    column: string;
+    targetSchema: string;
+    targetTable: string;
+    targetColumn: string;
+    sql: string;
+}
+/** A column a `relation` or `reference` property owns on its own table. */
+export interface RelationalColumnPlan {
+    schema: string;
+    /** Bare table name, no schema prefix. */
+    table: string;
+    column: string;
+    /** Postgres type, exactly as the DDL generator declares it. */
+    type: string;
+    /** Absent when the target collection is not part of this bundle. */
+    foreignKey?: ForeignKeyPlan;
+}
+/** The table behind a many-to-many `through` relation. */
+export interface JunctionTablePlan {
+    schema: string;
+    /** Bare table name, no schema prefix. */
+    table: string;
+    columns: {
+        name: string;
+        type: string;
+    }[];
+    /** Both endpoint columns plus the composite primary key. */
+    createTable: string;
+    foreignKeys: ForeignKeyPlan[];
+}
+/**
+ * The FK columns the declared collections own — one entry per `relation`
+ * (`belongsTo` side) or `reference` property.
+ *
+ * Split out of {@link generatePostgresDdl} so the boot-time schema ensure can
+ * create the same columns with the same names, types and constraints. Before
+ * this it skipped them outright, which was survivable only because `db push`
+ * always followed; on a managed tenant nothing follows, so a table arrived
+ * without the column its own collection reads and wrote 400 on every insert.
+ *
+ * A relation whose target is not in the bundle yields no column at all (the
+ * generator returns early on an unresolvable target); a `reference` whose target
+ * is unknown yields the column without a constraint. Both mirror the generator
+ * exactly — a divergence here is a schema fork between boot and `db push`.
+ */
+export declare const planRelationalColumns: (collections: CollectionConfig[]) => RelationalColumnPlan[];
+/**
+ * The junction tables a bundle's many-to-many relations imply.
+ *
+ * Derived from {@link resolveJunctionSpecs}, the same source the junction RLS
+ * comes from, so a table created here always has policies planned for it — a
+ * junction with row-level security left off is readable and writable by every
+ * signed-in user, which is why the two must ship together.
+ */
+export declare const planJunctionTables: (collections: CollectionConfig[]) => JunctionTablePlan[];
+export interface CollectionPolicyPlan {
+    /** The table's schema (e.g. `public`, `rebase`). */
+    schema: string;
+    /** The bare table name, no schema prefix. */
+    table: string;
+    /** `schema.table` — matches the keys `readExistingSchema` returns. */
+    qualified: string;
+    /** `ALTER TABLE … ENABLE ROW LEVEL SECURITY;` — locked by default. */
+    enableRls: string;
+    /** `DROP POLICY IF EXISTS` / `CREATE POLICY` statements, in order. */
+    policyStatements: string[];
+}
+/**
+ * The per-table RLS plan for the *declared* collections, as executable
+ * statements — what the managed runtime applies at boot so a freshly
+ * provisioned tenant database serves data instead of 401ing every read.
+ *
+ * Mirrors {@link generatePostgresPoliciesDdl} exactly (same
+ * `generatePolicyStatements`, same enable-RLS, same effective rules, same
+ * derived junction rules), so boot and `db push` produce identical policies from
+ * identical collections.
+ *
+ * Junction tables are included, and have to be: boot creates them now
+ * ({@link planJunctionTables}), and a junction with RLS left off is readable and
+ * writable by every signed-in user. A junction whose table is still absent is
+ * skipped by the applier, not planned away here.
+ */
+export declare const planCollectionPolicies: (collections: CollectionConfig[]) => CollectionPolicyPlan[];
 export declare const generatePostgresPoliciesDdl: (collections: CollectionConfig[]) => string;
+export {};

package/dist/schema/introspect-runtime.d.ts

@@ -7,7 +7,7 @@
  * single config file.
  *
  * Distinct from `introspect-db.ts`, which runs the same queries but emits
- * TypeScript *source* for a developer to edit and commit (CMS mode). The two
+ * TypeScript *source* for a developer to edit and commit (declared collections). The two
  * share the mapping helpers in `introspect-db-logic.ts` so a table is described
  * the same way whether it was generated or introspected.
  */

package/dist/services/FetchService.d.ts

@@ -20,6 +20,32 @@ export declare class FetchService {
      * Safely narrows the DrizzleClient union type to access db.query[tableName].
      */
     private getQueryBuilder;
+    /**
+     * The context the condition builder needs to compile a filter key that is
+     * not a column name outright.
+     *
+     * Two such keys. An owning relation's key resolves through the collection's
+     * relations to its foreign-key column; a relation whose link lives on the
+     * target table or in a junction resolves to a correlated `EXISTS`, which
+     * needs the registry to reach that other table and this table's key column
+     * to correlate back.
+     *
+     * Looked up rather than passed: every read path already has the path, only
+     * some have the collection, and a path that names no registered collection
+     * (a nested/derived one) is not an error here — the builder simply falls
+     * back to guessing the default key shapes, and a relation filter it cannot
+     * compile stays unresolvable and so fails closed.
+     */
+    private filterContext;
+    /**
+     * The table column this collection's rows are keyed by, or `undefined`.
+     *
+     * `getPrimaryKeys` rather than `requirePrimaryKeys`: a collection with no
+     * resolvable key is not an error on the filter path — it only means the
+     * relation filters that would correlate on it cannot be compiled, which
+     * the builder already handles by failing that field closed.
+     */
+    private resolveIdColumn;
     /**
      * Build filter conditions from FilterValues
      * Delegates to DrizzleConditionBuilder.buildFilterConditions
@@ -28,6 +54,15 @@ export declare class FetchService {
     /**
      * Resolves the correct Drizzle column for sorting.
      * Automatically maps owning relation property keys to their underlying foreign key column.
+     *
+     * The relation's own `localKey` is the authority for that foreign key, not
+     * `<field>_id`. The default local key comes from `generateForeignKeyName`,
+     * which snake-cases *and singularises* — `userProfile` → `user_profile_id`,
+     * `users` → `user_id` — and an author can override it outright. A wrong
+     * guess resolves to nothing, the caller drops the `ORDER BY`, and the rows
+     * come back in whatever order Postgres pleases: paging over that repeats
+     * and skips rows rather than erroring. The guesses stay, last, for a
+     * caller that hands over no collection to resolve against.
      */
     private resolveOrderByField;
     /**
@@ -35,7 +70,7 @@ export declare class FetchService {
      * Converts collection relations to a Drizzle-compatible `with` object.
      *
      * When `include` is provided, only those relations are loaded.
-     * When `include` is absent, ALL relations are loaded (CMS path).
+     * When `include` is absent, ALL relations are loaded (the admin path).
      *
      * Automatically detects many-to-many junction tables and nests
      * the target relation so actual row data is returned.

package/dist/services/row-pipeline.d.ts

@@ -10,7 +10,9 @@ import { PostgresCollectionRegistry } from "../collections/PostgresCollectionReg
  *
  * - `"ref"` — a `{ id, path, __type: "relation" }` reference carrying the
  *   target's values. This is what the admin renders.
- * - `"inline"` — the target's own columns, flat. This is what REST serves.
+ * - `"inline"` — the target's own columns, flat. This is what REST serves, and
+ *   — since the in-process SDK reads through the same pipeline — what
+ *   `rebase.data` / `context.data` serve too. A developer never sees a ref.
  *
  * They used to be two functions that happened to agree, and the agreement was
  * not enforced by anything: the row-identity bug had to be fixed five times