@rebasepro/server-postgres 0.9.1-canary.1d2d8b5 → 0.9.1-canary.58368ce

package/dist/PostgresBackendDriver.d.ts

@@ -3,7 +3,7 @@ import { BranchService } from "./services/BranchService";
 import { RealtimeService } from "./services/realtimeService";
 import { DatabasePoolManager } from "./databasePoolManager";
 import { DrizzleClient } from "./interfaces";
-import { DatabaseAdmin, DataDriver, DeleteProps, CollectionConfig, FetchCollectionProps, FetchOneProps, ListenCollectionProps, ListenOneProps, RebaseClient, RebaseSdkData, RestFetchService, SaveProps, TableMetadata, User } from "@rebasepro/types";
+import { DatabaseAdmin, DataDriver, DeleteProps, CollectionConfig, FetchCollectionProps, FetchOneProps, ListenCollectionProps, ListenOneProps, RebaseClient, RebaseSdkData, RestFetchService, SaveManyProps, SaveProps, TableMetadata, User } from "@rebasepro/types";
 import { PostgresCollectionRegistry } from "./collections/PostgresCollectionRegistry";
 import { HistoryService } from "./history/HistoryService";
 export declare class PostgresBackendDriver implements DataDriver {
@@ -88,7 +88,20 @@ export declare class PostgresBackendDriver implements DataDriver {
     listenCollection<M extends Record<string, unknown>>({ path, collection, filter, limit, offset, startAfter, orderBy, searchString, order, onUpdate, onError }: ListenCollectionProps<M>): () => void;
     fetchOne<M extends Record<string, unknown>>({ path, id, databaseId, collection }: FetchOneProps<M>): Promise<Record<string, unknown> | undefined>;
     listenOne<M extends Record<string, unknown>>({ path, id, collection, onUpdate, onError }: ListenOneProps<M>): () => void;
-    save<M extends Record<string, unknown>>({ path, id, values, collection, status }: SaveProps<M>): Promise<Record<string, unknown>>;
+    save<M extends Record<string, unknown>>({ path, id, values, collection, status, upsert }: SaveProps<M>): Promise<Record<string, unknown>>;
+    /**
+     * Write many rows through the same pipeline as {@link save}.
+     *
+     * The batch runs in one transaction of its own, so a failure part-way leaves
+     * nothing behind — the point of a batch is that a re-run starts from a known
+     * state. When this driver is already inside a transaction (the authenticated
+     * path, via `withTransaction`) the nested call becomes a savepoint, which is
+     * still atomic and still commits once.
+     *
+     * Rows are applied in order, so a batch that touches the same key twice ends
+     * with the last write winning, exactly as separate calls would.
+     */
+    saveMany<M extends Record<string, unknown>>({ path, rows, collection, upsert }: SaveManyProps<M>): Promise<Record<string, unknown>[]>;
     delete<M extends Record<string, unknown>>({ row, collection }: DeleteProps<M>): Promise<void>;
     deleteAll(path: string): Promise<void>;
     checkUniqueField(path: string, name: string, value: unknown, id?: string, collection?: CollectionConfig): Promise<boolean>;
@@ -143,6 +156,16 @@ export declare class AuthenticatedPostgresBackendDriver implements DataDriver {
     fetchOne<M extends Record<string, unknown>>(props: FetchOneProps<M>): Promise<Record<string, unknown> | undefined>;
     listenOne<M extends Record<string, unknown>>(props: ListenOneProps<M>): () => void;
     save<M extends Record<string, unknown>>(props: SaveProps<M>): Promise<Record<string, unknown>>;
+    /**
+     * One transaction for the whole batch, rather than one per row.
+     *
+     * This is the point of the method: `save` opens a transaction per call, so
+     * importing 10k rows through it means 10k transactions (and, over HTTP, 10k
+     * round trips). Here the RLS context is established once and every row lands
+     * or none does. Realtime notifications are already deferred to commit by
+     * `withTransaction`, so a batch does not flood subscribers mid-flight.
+     */
+    saveMany<M extends Record<string, unknown>>(props: SaveManyProps<M>): Promise<Record<string, unknown>[]>;
     delete<M extends Record<string, unknown>>(props: DeleteProps<M>): Promise<void>;
     deleteAll(path: string): Promise<void>;
     checkUniqueField(path: string, name: string, value: unknown, id?: string, collection?: CollectionConfig): Promise<boolean>;

package/dist/collections/buildRegistry.d.ts

@@ -0,0 +1,27 @@
+import { Relations } from "drizzle-orm";
+import { PgEnum } from "drizzle-orm/pg-core";
+import { CollectionConfig } from "@rebasepro/types";
+import { PostgresCollectionRegistry } from "./PostgresCollectionRegistry";
+/**
+ * Everything a registry is built from: the collections, and the drizzle schema
+ * they are backed by. In BaaS mode all of it is introspected from the live
+ * database; in CMS mode it comes from the config and the generated schema.
+ */
+export interface RegistrySchema {
+    collections?: CollectionConfig[];
+    tables?: Record<string, unknown>;
+    enums?: Record<string, PgEnum<[string, ...string[]]>>;
+    relations?: Record<string, Relations>;
+}
+/**
+ * Build the collection registry for a driver.
+ *
+ * The order matters and is the reason this is one function rather than a run of
+ * statements in the bootstrapper. Keys are resolved from the drizzle schema, so
+ * anything that inspects them has to run *after* the tables are registered —
+ * and `warnOnKeysTheAdminCannotResolve` fails open if it does not, because a
+ * collection whose table it cannot look up is one it has nothing to say about.
+ * Warned too early, it would skip every collection and report nothing, which
+ * reads exactly like having nothing to report.
+ */
+export declare function buildCollectionRegistry(schema: RegistrySchema): PostgresCollectionRegistry;

package/dist/data-transformer.d.ts

@@ -12,12 +12,19 @@ import { PostgresCollectionRegistry } from "./collections/PostgresCollectionRegi
 export interface SerializedEntityData {
     /** Scalar column values ready for INSERT/UPDATE. */
     scalarData: Record<string, unknown>;
-    /** Inverse relation updates that must be applied to target tables. */
+    /**
+     * Inverse relation updates that must be applied to target tables.
+     *
+     * No address here: the row being written does not know its own. These are
+     * applied by `PersistService`, which addresses them with the id it holds —
+     * the one it was given for an update, or the one the INSERT returned — and
+     * that is the authority. This item used to carry a `currentId` derived from
+     * the *input* values, which nothing ever read.
+     */
     inverseRelationUpdates: Array<{
         relationKey: string;
         relation: Relation;
         newValue: unknown;
-        currentId?: string | number;
     }>;
     /** JoinPath relation updates that require multi-hop writes. */
     joinPathRelationUpdates: Array<{