@rebasepro/server-postgres 0.13.0 → 0.13.1-canary.g249daa1

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, SaveManyProps, SaveProps, TableMetadata, User } from "@rebasepro/types";
+import { DatabaseAdmin, DataDriver, DeleteProps, CollectionConfig, FetchCollectionProps, FetchOneProps, ListenCollectionProps, ListenOneProps, RebaseClient, RebaseSdkData, RestFetchService, SaveManyProps, SaveProps, UpdateManyProps, DeleteManyProps, TableMetadata, User } from "@rebasepro/types";
 import { PostgresCollectionRegistry } from "./collections/PostgresCollectionRegistry";
 import { HistoryService } from "./history/HistoryService";
 export declare class PostgresBackendDriver implements DataDriver {
@@ -62,6 +62,25 @@ export declare class PostgresBackendDriver implements DataDriver {
      * REST/SDK read leaks unmasked data (see {@link applyAfterReadForRest}).
      */
     get restFetchService(): RestFetchService;
+    /**
+     * Build the context handed to every collection callback.
+     *
+     * Note `data: this.data` — `this` is whichever driver is running the
+     * operation, so the callback's data plane inherits that driver's privilege.
+     * On a user request `AuthenticatedPostgresBackendDriver.withTransaction`
+     * constructs a fresh base driver bound to the RLS-scoped transaction and
+     * runs the operation on it, so `this.data` speaks through that connection
+     * and policies apply. On server-context work `this` is the base driver on
+     * the owner connection, and they do not. Pinned by the
+     * `"scopes context.data to the caller"` case in the `rls-enforcement` e2e
+     * suite, because it is the kind of property that is easy to break from a
+     * distance and impossible to notice.
+     *
+     * Previously returned through `as unknown as RebaseCallContext`, which
+     * disabled checking for the whole object and let `driver` — documented in
+     * the callbacks guide — sit on the runtime context while absent from the
+     * contract. Both are declared now, so this is a plain typed return.
+     */
     private buildCallContext;
     private resolveCollectionCallbacks;
     /**
@@ -102,6 +121,34 @@ export declare class PostgresBackendDriver implements DataDriver {
      * 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>[]>;
+    /**
+     * Update many rows through the same pipeline as {@link save}, in one
+     * transaction.
+     *
+     * Structurally the mirror of {@link saveMany} — same tx-bound sub-driver,
+     * same deferred notifications, same per-row error labelling — but it calls
+     * `save` with an explicit `id` and `status: "existing"`, which is precisely
+     * what `saveMany` cannot do: that one passes `status: "new"` and keeps the
+     * key inside `values`, so it inserts or upserts and can never target a
+     * particular row.
+     *
+     * All-or-nothing, so an id matching no row aborts the batch. A partial
+     * update is the outcome with no good recovery: the caller cannot tell which
+     * half landed without re-reading everything.
+     */
+    updateMany<M extends Record<string, unknown>>({ path, updates, collection }: UpdateManyProps<M>): Promise<Record<string, unknown>[]>;
+    /**
+     * Delete many rows in one transaction, running the full delete pipeline —
+     * `beforeDelete`, the delete, `afterDelete` — for each.
+     *
+     * Looping the single-row {@link delete} rather than emitting one
+     * `DELETE ... WHERE id = ANY($1)` is the deliberate choice: a single
+     * statement would be faster and would skip every callback, so a collection
+     * relying on `beforeDelete` to veto or on `afterDelete` to clean up
+     * dependents would behave differently depending on how many rows the caller
+     * happened to delete at once. Same pipeline, one transaction.
+     */
+    deleteMany<M extends Record<string, unknown>>({ path, ids, collection }: DeleteManyProps<M>): Promise<void>;
     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>;