Repository navigation
Filter grammar: search / OR-AND / leading-wildcard / in-cap / nesting-cap are TS-only — decide cross-port or document as TS-only-by-design #32
Description
Context
A unit-test → conformance survey (FR-033 follow-up) found that five generated-API filter-grammar features are implemented only in the TypeScript runtime (runtime-ts filter-parser). The other four ports (Java, Kotlin, Python, C#) do not implement them. They are therefore not conformance-promotable today — a shared fixture would fail four lanes.
This issue tracks the product decision: implement these cross-port, or formally document them as TS-only-by-design.
TS-only features (audited, with per-port evidence)
| Feature | TS | Java | Kotlin | Python | C# | Fix size |
|---|---|---|---|---|---|---|
?search=<term> (OR a LIKE across @filterable string fields) |
✅ | ❌ | ❌ | ❌ | ❌ | Medium (runtime, ~50 LOC/port) |
filter[or][N] / filter[and][N] boolean combinators |
✅ | ❌ | ❌ | ❌ | ❌ | High (recursive parser, all 4) |
Leading-wildcard LIKE gating (@leadingWildcard opt-in → filter.leading_wildcard_disallowed 400) |
✅ | ❌ | ❌ | ❌ | ❌ | Medium-High (allowlist + runtime + possibly a metamodel attr) |
in-list size cap (>100 → 400) |
✅ | ❌ | ❌ | ❌ | ❌ | Low (~5 LOC/port) |
| Filter nesting-depth cap (>5 → 400) | ✅ | ❌ | ❌ | ❌ | ❌ | Low (depends on OR/AND) |
Evidence: TS impl in server/typescript/packages/runtime-ts/src/drizzle-fastify/filter-parser.ts; the other ports' FilterParser (Java codegen-spring/.../runtime/FilterParser.java, Python codegen/runtime/filter_parser.py, C# MetaObjects.Codegen/Runtime/FilterParser.cs, Kotlin controller) have no equivalent.
Current posture
MetaObjects.Codegen/Runtime/FilterParser.cs KNOWN_GAPS already explicitly defers filter[or]/filter[and] as "out of scope of FR-009 … defer until real consumer demand." So the de-facto project posture is already TS-only until demand.
Decision needed
- Option A — TS-only by design (recommended default). Document the divergence in
docs/features/api-contract.md(a "TS-only filter extensions" note) so adopters know these are not part of the cross-port contract. No code change. - Option B — implement cross-port. Port the wanted feature(s) to the other 4 ports + add api-contract conformance scenarios. Likely driven by real consumer demand for a specific feature (e.g.
?search=), not all five at once.
Out of scope / already cross-port (for reference)
invalid_filter_field / invalid_filter_op / invalid_filter_value 400s are implemented in all 5 ports (field+op already gated by filter-invalid-field.yaml/filter-invalid-op.yaml; an invalid_filter_value scenario is a separate low-risk add). ERR_YAML_COERCION is already gated by the error-yaml-coerced-* fixtures.
Activity
docs(#32): document TS-only filter extensions (not the cross-port con…
fix(#32): unify filter in-list size cap (100 -> 400) cross-port (#150)
dmealing commentedon Jul 29, 2026
Resolved as Option A (TS-only by design) — already documented.
docs/features/api-contract.mdhas a "TS-only filter extensions (not part of the cross-port contract)" section covering all five audited behaviors:?search=,filter[or]/filter[and]combinators, leading-wildcard gating, filter nesting-depth cap, and thein-list size cap (flagged as the one consistency/safety item worth unifying cross-port regardless of feature demand). Adopters are told not to assume these on a non-TS backend. Closing as documented; cross-port implementation (Option B) remains demand-driven if a specific consumer needs one.