@rebasepro/server-postgres 0.17.3-canary.gdd23447 → 0.18.0

package/src/services/row-pipeline.ts

@@ -1,240 +0,0 @@
-import { CollectionConfig, Property, ResolvedRelation, isManyToMany, type ResolvedVia } from "@rebasepro/types";
-import { resolveCollectionRelations, findRelation, createRelationRefWithData } from "@rebasepro/common";
-import { normalizeDbValues } from "../data-transformer";
-import { deriveRowAddress } from "./collection-helpers";
-import { PostgresCollectionRegistry } from "../collections/PostgresCollectionRegistry";
-
-/**
- * Turning a drizzle result into a row we serve.
- *
- * There are two shapes, and they are the same walk. Both take a row whose
- * relation fields hold nested objects, both unwrap junction rows to reach the
- * target behind them, and both leave every other column alone. They differ only
- * in what they put where the relation was:
- *
- * - `"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, 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
- * across differently-shaped copies of this walk, and one of the copies was
- * dead code nobody had noticed. Whatever the next cross-cutting change is, it
- * is one edit here.
- */
-export type RelationStyle = "ref" | "inline";
-
-/**
- * Whether a many-relation reaches its target through a junction table.
- *
- * Also used to build the drizzle `with` config, which is why it is exported:
- * the query has to nest one level deeper for a junction, and the row walk has
- * to unwrap that same level back out.
- */
-export function isJunctionRelation(relation: ResolvedRelation): boolean {
-    // An explicit `through` says so outright.
-    if (isManyToMany(relation)) return true;
-    // A multi-hop join path is the same thing spelled longhand.
-    return relation.kind === "via" && relation.joinPath.length > 1;
-}
-
-/**
- * Reach the target row inside a junction row.
- *
- * A junction row looks like `{ post_id: 1, tag_id: { id: 5, name: "ts" } }` —
- * the foreign keys, and the target nested under one of them. The target is the
- * only object among them, so that is how it is found. A junction row that has
- * not been nested (no `with` on the join) has no object and is returned as-is.
- */
-function unwrapJunctionRow(item: Record<string, unknown>): Record<string, unknown> {
-    const nestedKey = Object.keys(item).find(
-        key => typeof item[key] === "object" && item[key] !== null && !Array.isArray(item[key])
-    );
-    return nestedKey ? item[nestedKey] as Record<string, unknown> : item;
-}
-
-/**
- * Give back the number a `number` property was declared to be.
- *
- * Postgres returns NUMERIC as a string and drizzle keeps it that way, since a
- * numeric can hold more precision than a double. But the collection declared
- * this property `number` and the OpenAPI spec this server publishes says
- * `type: number`, so serving `"9.99"` breaks its own contract — and breaks it
- * asymmetrically, because a create answers with the number and the read that
- * follows answers with the string. Any client that multiplies a price works
- * until the first refresh.
- *
- * Declaring a property `number` already accepts double precision — that is what
- * the admin has always parsed it to. Columns REST serves that no property
- * declares are left exactly as the database returned them.
- */
-function coerceDeclaredNumber(value: unknown, property: Property | undefined): unknown {
-    if (property?.type !== "number" || typeof value !== "string") return value;
-    const parsed = parseFloat(value);
-    return isNaN(parsed) ? null : parsed;
-}
-
-/** Apply {@link coerceDeclaredNumber} across a row, leaving every other column alone. */
-function coerceDeclaredNumbers(
-    row: Record<string, unknown>,
-    collection: CollectionConfig
-): Record<string, unknown> {
-    const properties = collection.properties;
-    if (!properties) return row;
-
-    const out: Record<string, unknown> = {};
-    for (const [key, value] of Object.entries(row)) {
-        out[key] = coerceDeclaredNumber(value, properties[key] as Property | undefined);
-    }
-    return out;
-}
-
-/** Render one target row in the requested style. */
-/**
- * Drop every column the collection marked `excludeFromApi`.
- *
- * Password hashes and verification tokens have to be readable server-side but
- * must never reach a client — and "never" has to mean every exit from this
- * pipeline, including relation targets, or a secret leaks through whichever
- * path was overlooked. Keyed by both the property name and its column name,
- * since a row can arrive keyed either way depending on the caller.
- */
-function stripExcluded(
-    row: Record<string, unknown>,
-    collection: CollectionConfig
-): Record<string, unknown> {
-    const properties = collection.properties as Record<string, Property> | undefined;
-    if (!properties) return row;
-
-    for (const [key, property] of Object.entries(properties)) {
-        if (!property?.excludeFromApi) continue;
-        delete row[key];
-        if (property.columnName) delete row[property.columnName];
-    }
-    return row;
-}
-
-function renderTarget(
-    targetRow: Record<string, unknown>,
-    targetCollection: CollectionConfig,
-    style: RelationStyle,
-    registry: PostgresCollectionRegistry
-): unknown {
-    if (style === "inline") {
-        // The target's columns, and only those: its address is the consumer's
-        // to derive, and merging one in overwrites a real `id` column.
-        return stripExcluded(coerceDeclaredNumbers({ ...targetRow }, targetCollection), targetCollection);
-    }
-
-    const address = relationTargetAddress(targetRow, targetCollection, registry);
-    const path = targetCollection.slug;
-    return createRelationRefWithData(address, path, {
-        id: address,
-        path,
-        values: normalizeDbValues(targetRow, targetCollection)
-    });
-}
-
-/**
- * The address a relation ref points at.
- *
- * The whole key, not its first column: a composite-keyed target addressed by
- * `tenant_id` alone points at every row that shares it. A target whose key
- * cannot be resolved at all used to throw here — reading `[0]` of an empty
- * array — taking down the parent's fetch over a relation it may not even have
- * asked for. The first column is a guess, but a ref that resolves to nothing
- * beats no rows at all.
- */
-export function relationTargetAddress(
-    targetRow: Record<string, unknown>,
-    targetCollection: CollectionConfig,
-    registry: PostgresCollectionRegistry
-): string {
-    const address = deriveRowAddress(targetRow, targetCollection, registry);
-    if (address) return address;
-    return String(targetRow[Object.keys(targetRow)[0]] ?? "");
-}
-
-/**
- * The row the admin renders: every column, with relations as references.
- *
- * Values are normalized (dates, numbers, NaN) because the admin's view-model
- * expects real types. The row's own address is *not* among the columns — it is
- * derived by the consumer from the collection's primary keys.
- */
-export function toFlatRow(
-    row: Record<string, unknown>,
-    collection: CollectionConfig,
-    registry: PostgresCollectionRegistry
-): Record<string, unknown> {
-    const resolvedRelations = resolveCollectionRelations(collection);
-    const normalized = normalizeDbValues(row, collection) as Record<string, unknown>;
-
-    // Keyed by relation, reading the drizzle relation name off the raw row: the
-    // relation's property key and the name drizzle nested it under are not
-    // always the same, and the value is written back under the property key.
-    for (const [key, relation] of Object.entries(resolvedRelations)) {
-        const relData = row[relation.relationName || key];
-        if (relData === undefined || relData === null) continue;
-
-        if (relation.cardinality === "many" && Array.isArray(relData)) {
-            const targetCollection = relation.target();
-            normalized[key] = relData.map((item: Record<string, unknown>) =>
-                renderTarget(
-                    isJunctionRelation(relation) ? unwrapJunctionRow(item) : item,
-                    targetCollection,
-                    "ref",
-                    registry
-                ));
-        } else if (relation.cardinality === "one" && typeof relData === "object" && !Array.isArray(relData)) {
-            normalized[key] = renderTarget(relData as Record<string, unknown>, relation.target(), "ref", registry);
-        }
-    }
-
-    return stripExcluded(normalized, collection);
-}
-
-/**
- * The row REST serves: every column under its own name, with the value Postgres
- * returned, and relations inlined as the target's columns.
- *
- * Values are the ones the database returned, except where that contradicts the
- * declared type: a `number` property is served as a number (see
- * {@link coerceDeclaredNumber}). Dates stay as the database returned them —
- * JSON has its own opinions about dates that the admin's view-model does not
- * share.
- *
- * Keyed by the row rather than by the relation list — a REST fetch only loads
- * the relations `include` asked for, so the row is the authority on which are
- * actually there.
- */
-export function toRestRow(
-    row: Record<string, unknown>,
-    collection: CollectionConfig,
-    registry: PostgresCollectionRegistry
-): Record<string, unknown> {
-    const resolvedRelations = resolveCollectionRelations(collection);
-    const flat: Record<string, unknown> = {};
-
-    for (const [key, value] of Object.entries(row)) {
-        const relation = findRelation(resolvedRelations, key);
-
-        if (relation && Array.isArray(value)) {
-            flat[key] = value.map((item: Record<string, unknown>) =>
-                renderTarget(
-                    isJunctionRelation(relation) ? unwrapJunctionRow(item) : item,
-                    relation.target(),
-                    "inline",
-                    registry
-                ));
-        } else if (relation && typeof value === "object" && value !== null) {
-            flat[key] = renderTarget(value as Record<string, unknown>, relation.target(), "inline", registry);
-        } else {
-            flat[key] = coerceDeclaredNumber(value, collection.properties?.[key] as Property | undefined);
-        }
-    }
-
-    return stripExcluded(flat, collection);
-}

package/src/services/write-denial.ts

@@ -1,55 +0,0 @@
-import { and, sql, SQL } from "drizzle-orm";
-import { PgTable } from "drizzle-orm/pg-core";
-import { ApiError } from "@rebasepro/server";
-import { DrizzleClient } from "../interfaces";
-
-/**
- * Explain a write that matched no rows.
- *
- * Row-level security filters UPDATE and DELETE through the policy's USING
- * clause instead of raising: a denied write is reported by Postgres exactly
- * like a successful one that happened to match nothing. Left unchecked, a
- * caller cannot tell "denied" from "done" — the write returns 200/204 and the
- * row is untouched. An agent handed a key with `orders:delete` and no delete
- * policy is the case that makes it concrete: it deletes nothing, forever, and
- * is told it worked every time.
- *
- * Re-reading the target over the *same* RLS-scoped handle separates the two
- * cases. A visible row means the policy rejected the write (403); an invisible
- * one means there is nothing there to write for this caller (404, matching what
- * a GET would say). The re-read is bound by the caller's own policies, so it
- * discloses nothing a plain read wouldn't.
- *
- * Only reached when zero rows matched, so the happy path pays nothing.
- *
- * It lives here, rather than beside its first caller, because every zero-row
- * write has to answer the same question and answer it identically: the rule
- * that a readable-but-unwritable target is a 403 is the contract, and a second
- * copy of it is a second chance to get it wrong.
- *
- * @param handle     The RLS-scoped connection the write ran on — not a fresh
- *                   one, or the re-read would answer for a different caller.
- * @param table      The table the write targeted (the junction, for a link).
- * @param conditions The write's own WHERE terms, reused verbatim.
- * @param denied     Message for the 403: the target is there and was refused.
- * @param missing    Message for the 404: there is nothing there for this caller.
- */
-export async function explainZeroRowWrite(
-    handle: DrizzleClient,
-    table: PgTable,
-    conditions: SQL[],
-    denied: string,
-    missing: string
-): Promise<ApiError> {
-    const visible = await handle
-        .select({ present: sql<number>`1` })
-        .from(table)
-        .where(and(...conditions))
-        .limit(1);
-
-    if (visible.length > 0) {
-        return ApiError.forbidden(denied, "WRITE_DENIED");
-    }
-
-    return ApiError.notFound(missing);
-}

package/src/types.ts

@@ -1,4 +0,0 @@
-import type { PgTable, AnyPgColumn } from "drizzle-orm/pg-core";
-
-/** Drizzle PgTable with column access by name. Runtime Drizzle tables satisfy this shape. */
-export type RebasePgTable = PgTable & Record<string, AnyPgColumn>;

package/src/utils/connection-string.ts

@@ -1,58 +0,0 @@
-/**
- * Connection-string rewrites for the tools Rebase shells out to.
- *
- * Pure and dependency-free: `pg-tools` builds argument vectors without a live
- * server, and these have to be usable from there.
- */
-
-/**
- * The `sslmode` values libpq accepts. `no-verify` is conspicuously not one.
- */
-const LIBPQ_SSLMODES = new Set(["disable", "allow", "prefer", "require", "verify-ca", "verify-full"]);
-
-/**
- * Make a connection string safe to hand to a libpq program.
- *
- * `sslmode=no-verify` is a node-postgres convention — encrypt, but do not check
- * the certificate — and libpq does not have it. It does not degrade or warn:
- *
- *     psql: error: invalid sslmode value: "no-verify"
- *
- * which means a `DATABASE_URL` that works perfectly for the app makes `psql`,
- * `pg_dump`, `pg_restore` and Atlas all refuse to start, with an error that
- * points at the value rather than at the convention it comes from. It has cost
- * this project time more than once.
- *
- * `require` is the honest translation: libpq's `require` encrypts and does not
- * verify the certificate either, which is exactly what `no-verify` asks for.
- * Nothing is relaxed by the rewrite — `verify-ca` and `verify-full` are left
- * alone, so a connection string that asked for verification still gets it.
- *
- * Only `sslmode` is touched, and only when it is a value libpq would reject.
- * Anything unparseable is returned as given: a connection that works
- * unverified beats one this corrupted.
- */
-export function forLibpq(connectionString: string): string {
-    let url: URL;
-    try {
-        url = new URL(connectionString);
-    } catch {
-        // Key/value DSNs and anything else we cannot parse. A `sslmode` in one
-        // of those is space-separated rather than a query parameter, and
-        // rewriting it with a regex is how a password containing "sslmode="
-        // gets mangled.
-        return connectionString;
-    }
-    if (url.protocol !== "postgres:" && url.protocol !== "postgresql:") return connectionString;
-
-    const sslmode = url.searchParams.get("sslmode");
-    if (sslmode === null || LIBPQ_SSLMODES.has(sslmode)) return connectionString;
-
-    url.searchParams.set("sslmode", "require");
-    // Re-serialize by hand for the reason `pinSearchPath` does: URLSearchParams
-    // writes a space as `+`, which node-postgres decodes and libpq does not.
-    url.search = Array.from(url.searchParams.entries())
-        .map(([key, value]) => `${encodeURIComponent(key)}=${encodeURIComponent(value)}`)
-        .join("&");
-    return url.toString();
-}