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

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