@rebasepro/server-postgres 0.9.1-canary.d198c11 → 0.9.1-canary.d906fb7

package/dist/PostgresBootstrapper.d.ts

@@ -9,6 +9,7 @@ import { PostgresBackendDriver } from "./PostgresBackendDriver";
 import { RealtimeService } from "./services/realtimeService";
 import { DatabasePoolManager } from "./databasePoolManager";
 import { PostgresCollectionRegistry } from "./collections/PostgresCollectionRegistry";
+import { type CdcTableRef } from "./services/cdc/trigger-cdc";
 export interface PostgresDriverConfig {
     connectionString?: string;
     adminConnectionString?: string;
@@ -36,6 +37,15 @@ export interface PostgresDriverInternals {
     realtimeService: RealtimeService;
     driver: PostgresBackendDriver;
     poolManager?: DatabasePoolManager;
+    /**
+     * Attach CDC triggers to tables that did not exist when the driver
+     * bootstrapped. Only set when database-level capture is actually active.
+     *
+     * Auth owns its own tables and creates them later in boot, so at driver
+     * bootstrap they are legitimately missing and get skipped; without this
+     * they would stay uninstrumented until the next restart.
+     */
+    provisionCdcForTables?: (tables: CdcTableRef[]) => Promise<void>;
 }
 /**
  * Default PostgreSQL bootstrapper.

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<{