You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs(spec): the element-number D3 entry names the route hop — arrays are lowered by parseFilterAST before the analytics wire (#15828) (#15941)
The `element-number-filter-rule-array` semantic migration entry recorded its
runtime prerequisite at the wrong hop: "authored array → adapter lowering →
filter AST → accepted by `lowerAnalyticsWhere`". Per the `FilterArray` docblock
(#5158 ruling C) a `FilterArray` is input-only sugar lowered at the single sink
`parseFilterAST`; the wire's door is `POST /analytics/query`, which parses
`where` with `AnalyticsQueryRequestSchema` (a `FilterCondition` only) before any
service code runs. `lowerAnalyticsWhere` is the in-process door (#5334) for
direct `analyticsService.query` callers, not the wire's.
Prose only: the entry's reason clause, one sentence on
`AnalyticsQuerySchema.where`'s `.describe()`, the regenerated migration registry
and the two regenerated docs reference pages. No schema, accept-set, runtime or
test-behaviour change. The adapter-side fix is objectui#7752.
Claude-Session: https://claude.ai/code/session_01TezFG8ZMrNH6n5VTNpPpdH
Co-authored-by: Claude <noreply@anthropic.com>
Documentation: the analytics `where` contract and the `element:number` D3 entry now name the hop an array filter is lowered at.
6
+
7
+
Text only — no schema, accept-set, runtime or test behaviour changes. `AnalyticsQuerySchema.where` is still `FilterConditionSchema` and still refuses an array, which is the protocol working as `FilterArray`'s docblock (#5158 ruling C) declares it: a `FilterArray` is input-only authoring sugar, lowered to a `FilterCondition` at the single sink `parseFilterAST` (`@objectstack/spec/data`) the moment it arrives, and only the lowered `FilterCondition` travels any further.
8
+
9
+
-`AnalyticsQuerySchema.where`'s `.describe()` gains one sentence pointing array authors at that lowering: an authored `FilterArray` is lowered by `parseFilterAST` on the client before the wire, and this field admits only the lowered `FilterCondition`. It lands in the generated `content/docs/references/{api,data}/analytics.mdx` prop tables, which is where an author reads it.
10
+
- The `element-number-filter-rule-array` semantic migration entry recorded its runtime prerequisite one hop too late: "authored array → adapter lowering → filter AST → accepted by `lowerAnalyticsWhere`". `lowerAnalyticsWhere` (`service-analytics`) is the in-process door (#5334) for callers reaching `analyticsService.query` directly. The wire's door is the runtime route `POST /analytics/query`, which parses `where` with `AnalyticsQueryRequestSchema` before any service code runs, so an un-lowered array is refused there. The entry's reason clause now names that route hop and the `parseFilterAST` lowering the adapter owes before the wire (#15828; the adapter-side fix is objectui#7752).
11
+
12
+
The sibling entry `element-record-picker-filter-rule-array` was read for the same claim and does not make it — its measured path is `find()` / `convertQueryParams`, not the analytics wire — so it is unchanged.
|**where**|`any`| optional | Filtering criteria (canonical Query DSL FilterCondition). An authored `FilterArray` is lowered by `parseFilterAST` on the client before the wire; this field admits only the lowered `FilterCondition` (see `FilterArray` in `data/filter.zod.ts`).|
|**where**|`any`| optional | Filtering criteria (canonical Query DSL FilterCondition). An authored `FilterArray` is lowered by `parseFilterAST` on the client before the wire; this field admits only the lowered `FilterCondition` (see `FilterArray` in `data/filter.zod.ts`).|
0 commit comments