@rebasepro/server-postgres 0.11.1-canary.gfd39654 → 0.12.0

package/dist/utils/drizzle-conditions.d.ts

@@ -1,7 +1,54 @@
 import { SQL } from "drizzle-orm";
 import { AnyPgColumn, PgTable } from "drizzle-orm/pg-core";
-import { FilterValues, WhereFilterOp, LogicalCondition, FilterCondition, ResolvedRelation } from "@rebasepro/types";
+import { CollectionConfig, FilterValues, WhereFilterOp, LogicalCondition, FilterCondition, ResolvedRelation, ResolvedForeignKeyOnTarget, ResolvedManyToMany } from "@rebasepro/types";
 import { PostgresCollectionRegistry } from "../collections/PostgresCollectionRegistry";
+/**
+ * What to do with a filter field that resolves to no column at all.
+ *
+ *  - `"error"` (default) — reject the request. A filter that cannot be
+ *    compiled is *dropped*, and dropping a condition can only ever widen the
+ *    result set. On a data plane where row-level security is the last line of
+ *    defence, a typo'd or renamed filter key therefore runs the query without
+ *    that condition and returns everything RLS happens to allow.
+ *  - `"warn"` — the historical behaviour: log and silently drop the condition.
+ *    Only for a deployment that knowingly sends filter keys the table does not
+ *    have and has satisfied itself that widening is safe there.
+ */
+export type UnknownFilterFieldsMode = "error" | "warn";
+/** Set the process-wide behaviour for unresolvable filter fields. */
+export declare function configureUnknownFilterFields(mode: UnknownFilterFieldsMode): void;
+/** The process-wide behaviour for unresolvable filter fields. */
+export declare function getUnknownFilterFieldsMode(): UnknownFilterFieldsMode;
+/** Per-call context for compiling a filter into SQL. */
+export interface FilterCompilationOptions {
+    /**
+     * Overrides the process-wide {@link UnknownFilterFieldsMode} for this call.
+     */
+    unknownFields?: UnknownFilterFieldsMode;
+    /**
+     * The collection the filter is written against. Its resolved relations are
+     * what turn an owning-relation filter key into the foreign-key column it
+     * actually lives in; without it only the default key shapes can be guessed.
+     */
+    collection?: CollectionConfig;
+    /**
+     * The driver's registry, for relations whose link is not on this row at
+     * all. A `manyToMany` compiles to an `EXISTS` over its junction and a
+     * `hasMany`/`hasOne` to one over the target table — neither of which this
+     * builder can reach from the collection alone.
+     */
+    registry?: PostgresCollectionRegistry;
+    /**
+     * The key column of the table being filtered — what those `EXISTS`
+     * subqueries correlate back to.
+     *
+     * It has to be the Drizzle column object rather than a name: a column
+     * renders qualified with its own table, which is what binds it to the
+     * *outer* row instead of to the junction or target aliased inside the
+     * subquery. See {@link DrizzleConditionBuilder.buildRelationFilterCondition}.
+     */
+    sourceIdColumn?: AnyPgColumn;
+}
 /** Drizzle dynamic query builder — accepts innerJoin + where chaining */
 export interface DrizzleDynamicQuery {
     innerJoin(table: PgTable<any>, condition: SQL): this;
@@ -59,14 +106,121 @@ export declare class DrizzleConditionBuilder {
      * that revisits a table (a self-referencing many-to-many) unambiguous.
      */
     private static buildJoinPathScopeCondition;
+    /**
+     * What a filter field names, or `undefined` if it names nothing.
+     *
+     * Three ways a field resolves. It may address its column directly; it may
+     * be an owning relation, whose foreign key is a column here; or it may be
+     * a relation whose link lives on another table entirely, which compiles to
+     * a subquery instead of a column. Only a field that resolves to *none* of
+     * them is an error, and by default it is one: see
+     * {@link UnknownFilterFieldsMode} for why silently dropping it is a
+     * data-exposure primitive rather than a convenience.
+     *
+     * For an owning relation the relation's own `localKey` is the authority,
+     * not `<field>_id`. The default local key is `generateForeignKeyName`,
+     * which snake-cases *and singularises* — `userProfile` → `user_profile_id`,
+     * `users` → `user_id` — and it can be overridden outright. Guessing
+     * `<field>_id` therefore misses perfectly ordinary owning relations, and
+     * with this resolution failing closed that miss is a 400 on a filter that
+     * has nothing wrong with it. The guesses stay, last, for callers that hand
+     * over no collection to resolve against.
+     *
+     * The subquery kinds need a registry and the source table's key column on
+     * top of the collection. A caller that supplies neither gets the behaviour
+     * it had before they were compilable — unresolvable, and so fail-closed —
+     * rather than a half-built condition.
+     */
+    private static resolveFilterTarget;
     /**
      * Build filter conditions from FilterValues
      */
-    static buildFilterConditions<M extends Record<string, unknown>>(filter: FilterValues<Extract<keyof M, string>>, table: PgTable<any>, collectionPath: string): SQL[];
+    static buildFilterConditions<M extends Record<string, unknown>>(filter: FilterValues<Extract<keyof M, string>>, table: PgTable<any>, collectionPath: string, options?: FilterCompilationOptions): SQL[];
     /**
      * Build logical conditions recursively from LogicalCondition or FilterCondition
      */
-    static buildLogicalConditions(cond: LogicalCondition | FilterCondition, table: PgTable<any>, collectionPath: string): SQL | null;
+    static buildLogicalConditions(cond: LogicalCondition | FilterCondition, table: PgTable<any>, collectionPath: string, options?: FilterCompilationOptions): SQL | null;
+    /** Dispatch a resolved filter field onto the shape it actually compiles to. */
+    private static compileFilterTarget;
+    /**
+     * A filter on a relation that owns no column on this row — `EXISTS` over
+     * the rows it reaches.
+     *
+     * `posts` filtered by `tags == <tagId>` is not a comparison on `posts`; it
+     * is a question about the junction:
+     *
+     *     EXISTS (SELECT 1 FROM posts_tags AS j
+     *             WHERE j.post_id = posts.id AND j.tag_id = <tagId>)
+     *
+     * which is {@link buildRelationScopeCondition}'s many-to-many shape with
+     * source and target swapped — there the junction's *target* column
+     * correlates and the source is pinned; here the *source* column correlates
+     * and the target is what the filter constrains.
+     *
+     * `hasMany`/`hasOne` are the same shape one table over: the target row
+     * carries the foreign key, so the correlation is on that key and the
+     * compared column is the target's own id.
+     *
+     * `EXISTS` and not a join, for the reason the scope condition gives: a join
+     * through a junction multiplies the outer rows by the number of matching
+     * links, which duplicates results and silently breaks `limit`/`offset`.
+     *
+     * Everything inside the subquery is referenced by identifier against a
+     * local alias, and only `sourceIdColumn` stays a Drizzle column object —
+     * again see {@link buildRelationScopeCondition}, which explains why a
+     * column object renders against whatever table the surrounding builder
+     * thinks is current and so cannot be used for the inner references. The
+     * alias is also what keeps a self-referential relation unambiguous
+     * (`categories.children`, or a many-to-many whose junction and target are
+     * the same table), where the subquery's table and the outer one coincide.
+     */
+    static buildRelationFilterCondition(relation: ResolvedForeignKeyOnTarget | ResolvedManyToMany, op: WhereFilterOp, value: unknown, sourceIdColumn: AnyPgColumn, registry: PostgresCollectionRegistry, field: string, collectionPath: string): SQL;
+    /**
+     * The inner predicate of a relation filter, and whether the `EXISTS`
+     * wrapping it is negated.
+     *
+     * Negation is `NOT EXISTS` of the *positive* predicate, never `EXISTS` of a
+     * negated one. On a many-valued relation the two are different questions:
+     * `EXISTS (… AND tag_id != X)` asks "does some tag differ from X", which is
+     * true of nearly every post with more than one tag and answers nothing
+     * anybody asked. `NOT EXISTS (… AND tag_id = X)` asks "is X absent", which
+     * is what unticking a value in a filter control means — and it makes `==`
+     * and `!=` partition the rows, the way a filter implies they do.
+     *
+     * `is-null`/`is-not-null` drop the predicate entirely: with nothing but the
+     * correlation left, they become "has no related row at all" and "has at
+     * least one", which is the only reading of null a link can have.
+     *
+     * Under RLS, "no related row" means *no row this reader can see*. A junction
+     * with row-level security but no `SELECT` policy for `rebase_user` is opaque
+     * to it, so every row comes back looking unlinked and `is-null` matches all
+     * of them. That is not a leak — the outer table's own policies still decide
+     * which rows exist at all, and the positive direction correctly returns
+     * nothing — but it over-reports, and the cause is a missing junction policy
+     * rather than anything here. Rebase derives one for a declared many-to-many;
+     * a hand-written schema has to supply it.
+     *
+     * `in`/`not-in` against a *null value* mean the same thing, rather than
+     * membership of an empty list. Membership against null is not a membership
+     * question, and the admin's "filter for null values" control emits the
+     * operator that happens to be selected — on a to-many relation that is
+     * always `in` or `not-in`, because those are the only ones the multi-select
+     * can produce. Reading `["in", null]` as an empty list would answer "posts
+     * with no tags" with no posts at all.
+     *
+     * An empty `in` list compiles to `FALSE` rather than being dropped. Dropped
+     * is what the column path does, and dropping a condition widens the result
+     * — the whole reason this resolution fails closed. `in []` matches nothing
+     * and `not-in []` matches everything, and `NOT EXISTS (… AND FALSE)` gives
+     * the second for free.
+     *
+     * Anything else is rejected. Returning `null` for an operator this cannot
+     * express would drop the condition, and the operators the admin offers for
+     * a relation are exactly the six below.
+     */
+    private static buildRelationFilterPredicate;
+    /** The column a table's rows are keyed by: its primary key, else `id`. */
+    private static primaryKeyColumn;
     /**
      * Build a single filter condition for a specific operator and value
      */

package/dist/utils/pg-error-utils.d.ts

@@ -52,12 +52,15 @@ export declare function pgErrorToFriendlyMessage(pgError: PostgresError, context
 /**
  * Sanitize any error into a message safe and helpful for the client.
  *
- * Extracts the PG error from the Drizzle cause chain when possible;
- * falls back to a generic message that doesn't leak SQL.
+ * A deliberate 4xx (`ApiError`) passes through untouched — the server already
+ * decided what the client should read. Otherwise the PG error is extracted
+ * from the Drizzle cause chain, falling back to a generic message that
+ * doesn't leak SQL.
  *
  * @param error   - The raw caught error
  * @param context - A human-readable context string (e.g. collection path)
- * @returns An object with `message` (user-friendly) and optional `code` (PG code).
+ * @returns An object with `message` (user-friendly) and optional `code`
+ *          (the `ApiError` code, or the PG SQLSTATE).
  */
 export declare function sanitizeErrorForClient(error: unknown, context: string): {
     message: string;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rebasepro/server-postgres",
   "type": "module",
-  "version": "0.11.1-canary.gfd39654",
+  "version": "0.12.0",
   "description": "PostgreSQL data source backend implementation for Rebase with Drizzle ORM",
   "funding": {
     "url": "https://github.com/sponsors/rebaseco"
@@ -47,11 +47,11 @@
     "execa": "^9.6.1",
     "pg": "^8.21.0",
     "ws": "^8.21.0",
-    "@rebasepro/codegen": "0.11.1-canary.gfd39654",
-    "@rebasepro/server": "0.11.1-canary.gfd39654",
-    "@rebasepro/common": "0.11.1-canary.gfd39654",
-    "@rebasepro/types": "0.11.1-canary.gfd39654",
-    "@rebasepro/utils": "0.11.1-canary.gfd39654"
+    "@rebasepro/codegen": "0.12.0",
+    "@rebasepro/server": "0.12.0",
+    "@rebasepro/common": "0.12.0",
+    "@rebasepro/utils": "0.12.0",
+    "@rebasepro/types": "0.12.0"
   },
   "devDependencies": {
     "@hono/node-server": "^2.0.11",

package/src/PostgresBootstrapper.ts

@@ -15,6 +15,7 @@ import {
     DatabaseAdmin,
     type DataDriver,
     CollectionConfig,
+    isRelationalCollectionConfig,
     type HistoryConfig,
     InitializedDriver,
     RealtimeProvider,
@@ -41,6 +42,7 @@ import { provisionTriggerCdc, type CdcTableRef } from "./services/cdc/trigger-cd
 import { collectJunctionLinks } from "./services/cdc/junction-tables";
 import { createChannelBus, resolveChannelBusSetting } from "./services/channel-bus";
 import { isChannelBusInstance } from "@rebasepro/types";
+import { configureUnknownFilterFields, type UnknownFilterFieldsMode } from "./utils/drizzle-conditions";
 
 export interface PostgresDriverConfig {
     connectionString?: string;
@@ -67,6 +69,13 @@ export interface PostgresDriverConfig {
      *    instance and wrong for two. See {@link ChannelBusConfig}.
      */
     realtime?: RealtimeChannelsConfig;
+    /**
+     * What to do with a filter field that resolves to no column at all.
+     * Defaults to `"error"` — a filter that cannot be compiled would otherwise
+     * be dropped, and a dropped condition can only widen the result set.
+     * Set to `"warn"` to restore the pre-fix behaviour of dropping it silently.
+     */
+    unknownFilterFields?: UnknownFilterFieldsMode;
 }
 
 /**
@@ -106,16 +115,23 @@ import { isEconnrefused } from "./cli-errors";
  * ```
  */
 export function createPostgresBootstrapper(pgConfig: PostgresDriverConfig): BackendBootstrapper {
+    // Applied at construction rather than threaded through every read: the
+    // condition builder's static methods are reached from call sites that
+    // carry no config. See `UnknownFilterFieldsMode`.
+    if (pgConfig.unknownFilterFields) {
+        configureUnknownFilterFields(pgConfig.unknownFilterFields);
+    }
+
     return {
         type: "postgres",
 
         async initializeDriver(config: unknown): Promise<InitializedDriver> {
             // config is passed from coordinator, we merge it with our internal pgConfig if needed
             // Currently config from init.ts is `{ collections, collectionRegistry, mode }`
-            const { collections, collectionRegistry, mode, baas } = config as {
+            const { collections, collectionRegistry, introspectCollections, baas } = config as {
                 collections?: CollectionConfig[];
                 collectionRegistry?: unknown;
-                mode?: "cms" | "baas";
+                introspectCollections?: boolean;
                 baas?: { unprotectedTables?: "exclude" | "serve" };
             };
             // Secure by default: a table with no RLS is not served.
@@ -126,13 +142,13 @@ export function createPostgresBootstrapper(pgConfig: PostgresDriverConfig): Back
                 ? (connection as Record<string, unknown>).$client
                 : connection) as import("pg").Pool;
 
-            // ── BaaS mode: derive the schema from the database ───────────────
+            // ── No declared collections: derive the schema from the database ──
             // No collection files and no generated drizzle schema exist, so read
             // the live database and build both from what is actually there.
             let introspectedCollections: CollectionConfig[] | undefined;
             let introspectedTables: Record<string, PgTable> | undefined;
             let introspectedRelations: Record<string, Relations> | undefined;
-            if (mode === "baas" && (!collections || collections.length === 0)) {
+            if (introspectCollections && (!collections || collections.length === 0)) {
                 const pgSchemaName = pgConfig.introspectionSchema ?? "public";
                 const schema = await introspectSchema(rawClient, pgSchemaName);
 
@@ -497,10 +513,11 @@ table: link.table });
                         if ((col as { auth?: { enabled?: boolean } }).auth?.enabled) continue;
 
                         const schemaName = "schema" in col && col.schema ? col.schema : "public";
+                        const declaredTable = isRelationalCollectionConfig(col) ? col.table : undefined;
                         const tableName = registry.hasTableForCollection(
-                            col.table ?? col.slug
+                            declaredTable ?? col.slug
                         )
-                            ? (col.table ?? col.slug)
+                            ? (declaredTable ?? col.slug)
                             : col.slug;
                         // Resolve the actual table name the registry stored
                         const resolvedTable = registry.getTableNames().find((k) =>

package/src/collections/buildRegistry.ts

@@ -9,7 +9,7 @@ import { assertRelationsResolve } from "./validate-relations";
 /**
  * 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.
+ * database; when collections are declared it comes from the config and the generated schema.
  */
 export interface RegistrySchema {
     collections?: CollectionConfig[];

package/src/history/HistoryService.ts

@@ -1,39 +1,21 @@
 import { sql } from "drizzle-orm";
 import { NodePgDatabase } from "drizzle-orm/node-postgres";
 import { logger } from "@rebasepro/server";
+import type { EntityHistoryEntry } from "@rebasepro/types";
 
-export interface HistoryEntry {
-    id: string;
-    table_name: string;
-    entity_id: string;
-    action: "create" | "update" | "delete";
-    changed_fields: string[] | null;
-    values: Record<string, unknown> | null;
-    previous_values: Record<string, unknown> | null;
-    updated_by: string | null;
-    updated_at: string;
-}
-
-export interface RecordHistoryParams {
-    tableName: string;
-    id: string;
-    action: "create" | "update" | "delete";
-    values?: Record<string, unknown> | null;
-    previousValues?: Record<string, unknown> | null;
-    updatedBy?: string | null;
-}
-
-export interface FetchHistoryOptions {
-    limit?: number;
-    offset?: number;
-}
+export type {
+    RecordHistoryParams,
+    FetchHistoryOptions,
+    HistoryRetentionConfig
+} from "@rebasepro/types";
+import type { RecordHistoryParams, FetchHistoryOptions, HistoryRetentionConfig } from "@rebasepro/types";
 
-export interface HistoryRetentionConfig {
-    /** Max entries per row. Oldest pruned first. Default 200. */
-    maxEntries: number;
-    /** Entries older than this many days are pruned. Default 90. */
-    ttlDays: number;
-}
+/**
+ * A Postgres history row is already the wire shape — `updated_at` comes back
+ * from the driver as a string. Kept as an alias because the name is used
+ * throughout this package and in `PostgresBackendDriver`.
+ */
+export type HistoryEntry = EntityHistoryEntry;
 
 const DEFAULT_RETENTION: HistoryRetentionConfig = {
     maxEntries: 200,

package/src/schema/dynamic-tables.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/src/schema/generate-drizzle-schema-logic.ts

@@ -708,9 +708,17 @@ export const generateSchema = async (collections: CollectionConfig[], stripPolic
                     emittedRelationNames.add(deduplicationKey);
 
                     switch (rel.kind) {
-                        case "belongsTo":
-                            tableRelations.push(`    "${relationKey}": one(${targetTableVar}, {\n        fields: [${tableVarName}.${rel.localKey}],\n        references: [${targetTableVar}.${getPrimaryKeyName(target)}],\n        relationName: \"${drizzleRelationName}\"\n    })`);
+                        case "belongsTo": {
+                            // `localKey` is a COLUMN name; the generated Drizzle
+                            // object is keyed by PROPERTY. They differ whenever
+                            // the property is camelCase — `user_id` is exposed
+                            // as `userId` — and emitting the column produces a
+                            // schema that does not compile. The three other
+                            // emission sites normalise; this one did not.
+                            const localFieldKey = resolvePropertyKeyForColumn(collection, rel.localKey);
+                            tableRelations.push(`    "${relationKey}": one(${targetTableVar}, {\n        fields: [${tableVarName}.${localFieldKey}],\n        references: [${targetTableVar}.${getPrimaryKeyName(target)}],\n        relationName: \"${drizzleRelationName}\"\n    })`);
                             break;
+                        }
 
                         case "hasOne":
                             // The foreign key lives on the TARGET table. Drizzle pairs

package/src/schema/introspect-runtime.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/src/services/FetchService.ts

@@ -3,10 +3,12 @@ import { AnyPgColumn, PgTable } from "drizzle-orm/pg-core";
 import { CollectionConfig, FilterValues, ResolvedRelation, LogicalCondition, isManyToMany } from "@rebasepro/types";
 import type { VectorSearchParams } from "@rebasepro/types";
 import { resolveCollectionRelations, findRelation, createRelationRef, createRelationRefWithData } from "@rebasepro/common";
-import { DrizzleConditionBuilder } from "../utils/drizzle-conditions";
+import { generateForeignKeyName } from "@rebasepro/utils";
+import { DrizzleConditionBuilder, type FilterCompilationOptions } from "../utils/drizzle-conditions";
 import {
     getCollectionByPath,
     getTableForCollection,
+    getPrimaryKeys,
     requirePrimaryKeys,
     deriveRowAddress,
     parseIdValues,
@@ -45,6 +47,45 @@ export class FetchService {
         return query?.[tableName] as RelationalQueryBuilder<TablesRelationalConfig, TableRelationalConfig> | undefined;
     }
 
+    /**
+     * 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(collectionPath: string, table: PgTable<any>): FilterCompilationOptions {
+        const collection = this.registry.getCollectionByPath(collectionPath) ?? undefined;
+        return {
+            collection,
+            registry: this.registry,
+            sourceIdColumn: collection ? this.resolveIdColumn(collection, table) : undefined
+        };
+    }
+
+    /**
+     * 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(collection: CollectionConfig, table: PgTable<any>): AnyPgColumn | undefined {
+        const [idInfo] = getPrimaryKeys(collection, this.registry);
+        if (!idInfo) return undefined;
+        return table[idInfo.fieldName as keyof typeof table] as AnyPgColumn | undefined;
+    }
+
     /**
      * Build filter conditions from FilterValues
      * Delegates to DrizzleConditionBuilder.buildFilterConditions
@@ -54,7 +95,9 @@ export class FetchService {
         table: PgTable<any>,
         collectionPath: string
     ): SQL[] {
-        return DrizzleConditionBuilder.buildFilterConditions(filter, table, collectionPath);
+        return DrizzleConditionBuilder.buildFilterConditions(
+            filter, table, collectionPath, this.filterContext(collectionPath, table)
+        );
     }
 
     // =============================================================
@@ -64,20 +107,45 @@ export 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(
         table: PgTable<any>,
         orderBy: string,
         collection?: CollectionConfig
     ): AnyPgColumn | undefined {
-        let orderByField = table[orderBy as keyof typeof table] as AnyPgColumn;
-        if (!orderByField && collection) {
-            const property = collection.properties[orderBy];
-            if (property && property.type === "relation" && "relation" in property && property.resolvedRelation?.kind === "belongsTo") {
-                orderByField = table[`${orderBy}_id` as keyof typeof table] as AnyPgColumn;
+        const columnAt = (key: string): AnyPgColumn | undefined =>
+            (key in table ? table[key as keyof typeof table] as AnyPgColumn : undefined) || undefined;
+
+        const direct = columnAt(orderBy);
+        if (direct) return direct;
+
+        // Owning relation, resolved: the relation names its own local key.
+        if (collection) {
+            const relation = resolveCollectionRelations(collection)[orderBy];
+            if (relation?.kind === "belongsTo") {
+                const foreignKey = columnAt(relation.localKey);
+                if (foreignKey) return foreignKey;
             }
         }
-        return orderByField;
+
+        // No collection in hand — the two shapes an owning relation's key takes
+        // by default (e.g. `project` → `project_id`, `userProfile` →
+        // `user_profile_id`).
+        for (const guess of [`${orderBy}_id`, generateForeignKeyName(orderBy)]) {
+            const foreignKey = columnAt(guess);
+            if (foreignKey) return foreignKey;
+        }
+
+        return undefined;
     }
 
     /**
@@ -85,7 +153,7 @@ export 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.
@@ -311,7 +379,7 @@ export class FetchService {
         }
 
         if (options.logical) {
-            const logicalCondition = DrizzleConditionBuilder.buildLogicalConditions(options.logical, table, collectionPath);
+            const logicalCondition = DrizzleConditionBuilder.buildLogicalConditions(options.logical, table, collectionPath, this.filterContext(collectionPath, table));
             if (logicalCondition) allConditions.push(logicalCondition);
         }
 
@@ -656,7 +724,7 @@ _distance: vectorMeta.distanceSelect }).from(table).$dynamic()
         }
 
         if (options.logical) {
-            const logicalCondition = DrizzleConditionBuilder.buildLogicalConditions(options.logical, table, collectionPath);
+            const logicalCondition = DrizzleConditionBuilder.buildLogicalConditions(options.logical, table, collectionPath, this.filterContext(collectionPath, table));
             if (logicalCondition) allConditions.push(logicalCondition);
         }
 

package/src/services/row-pipeline.ts

@@ -14,7 +14,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