@rebasepro/server-postgres 0.11.1-canary.gf2b0ff7 → 0.11.1-canary.gfadf355

package/dist/schema/dynamic-tables.d.ts

@@ -1,7 +1,7 @@
 /**
  * Build drizzle tables at runtime from an introspected schema.
  *
- * CMS mode gets its drizzle tables from a generated `schema.generated.ts` that
+ * A project with declared collections gets its drizzle tables from a generated `schema.generated.ts` that
  * the developer commits. BaaS mode has no such file — it points at a database
  * and serves it — so the equivalent table objects are constructed here from
  * `information_schema` metadata.

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

package/dist/{src-D5xBTl32.js → src-C5hyt1Um.js}

@@ -261,6 +261,16 @@ function isChannelBusInstance(setting) {
 * @group Models
 */
 var DEFAULT_DATA_SOURCE_KEY = "(default)";
+/**
+* Relation kinds assumed filterable when a driver does not say.
+*
+* `belongsTo` alone: its filter is a comparison on a column of the row being
+* filtered, the one shape that needs no query construction a driver might not
+* have. Everything else is a correlated subquery over another table.
+*
+* @group Models
+*/
+var DEFAULT_FILTERABLE_RELATION_KINDS = ["belongsTo"];
 /** @group Models */
 var POSTGRES_CAPABILITIES = {
 	key: "postgres",
@@ -272,6 +282,12 @@ var POSTGRES_CAPABILITIES = {
 	supportsColumnTypes: true,
 	supportsRealtime: true,
 	filterOperators: ALL_WHERE_FILTER_OPS,
+	filterableRelationKinds: [
+		"belongsTo",
+		"manyToMany",
+		"hasMany",
+		"hasOne"
+	],
 	supportsSQLAdmin: true,
 	supportsDocumentAdmin: false,
 	supportsSchemaAdmin: true
@@ -287,6 +303,7 @@ var FIREBASE_CAPABILITIES = {
 	supportsColumnTypes: false,
 	supportsRealtime: true,
 	filterOperators: ALL_WHERE_FILTER_OPS.filter((op) => op !== "like" && op !== "ilike" && op !== "not-like" && op !== "not-ilike"),
+	filterableRelationKinds: [],
 	supportsSQLAdmin: false,
 	supportsDocumentAdmin: false,
 	supportsSchemaAdmin: false
@@ -302,6 +319,7 @@ var MONGODB_CAPABILITIES = {
 	supportsColumnTypes: false,
 	supportsRealtime: false,
 	filterOperators: ALL_WHERE_FILTER_OPS,
+	filterableRelationKinds: [],
 	supportsSQLAdmin: false,
 	supportsDocumentAdmin: true,
 	supportsSchemaAdmin: true
@@ -321,6 +339,7 @@ var DEFAULT_CAPABILITIES = {
 	supportsColumnTypes: true,
 	supportsRealtime: true,
 	filterOperators: ALL_WHERE_FILTER_OPS,
+	filterableRelationKinds: DEFAULT_FILTERABLE_RELATION_KINDS,
 	supportsSQLAdmin: true,
 	supportsDocumentAdmin: true,
 	supportsSchemaAdmin: true
@@ -343,4 +362,4 @@ function getDataSourceCapabilities(engine) {
 //#endregion
 export { isSchemaAdmin as a, hasForeignKeyOnTarget as c, isPostgresCollectionConfig as d, NULL_OPS as f, Vector as g, EntityRelation as h, isSQLAdmin as i, isManyToMany as l, toCanonicalOp as m, getDataSourceCapabilities as n, ANONYMOUS_USER_ID as o, REST_TO_CANONICAL as p, isChannelBusInstance as r, policy as s, DEFAULT_DATA_SOURCE_KEY as t, getDeclaredSubcollections as u };
 
-//# sourceMappingURL=src-D5xBTl32.js.map
+//# sourceMappingURL=src-C5hyt1Um.js.map