feat(tesseract): default value filters for views (CORE-357)

[waralexrom]

Summary

Adds support for view-level default value filters (CORE-357). A view can now declare:

filters:
  - member: currency
    operator: equals
    values: [USD]
    unless: [currency]

Whenever the view is touched by a query, the default filter is added; an explicit user filter on the same member can release it via unless. The motivating customer case is a switch dimension where the planner otherwise rolls up across all switch values.

[claude]

Claude finished @waralexrom's task in 3m 32s —— View job

---

Code Review: feat(tesseract): default value filters for views (CORE-357)

• Gather context and understand the full diff
• Review schema compiler changes (TypeScript)
• Review Rust bridge and planner changes
• Review test coverage
• Post comprehensive review feedback

---

Overall Assessment

This is a well-structured feature addition with clean layer separation — schema validation (Joi), reference resolution (CubeEvaluator), bridge definition (Rust ViewFilterDefinition), and query-time application (QueryPropertiesCompiler). The unless semantics (filter-only, projection doesn't release the guard) are a good design choice and well-documented throughout.

What Looks Good

• Layered validation: Joi catches structural errors early, CubeEvaluator.prepareViewFilters validates membership against includedMembers, and the Rust planner receives only resolved references. Each layer has clear responsibility.
• unless is filter-only: The decision that pulling a member into the projection doesn't silently change the row set is the right call. It's documented inline and tested explicitly in both Rust unit tests and integration tests.
• Comprehensive test coverage: Validator tests (valid/invalid operator, missing member, regular cube rejection), schema compiler tests (short/real-path/view-path resolution, unincluded members), Rust unit and integration tests, Postgres e2e tests, and bridge coverage tests. Hard to find a scenario that isn't covered.
• String coercion: Values are coerced to strings via String(v) in CubeEvaluator to match the Option<Vec<Option<String>>> contract used by regular query filters — nulls are preserved correctly.
• Bridge wiring: The new viewFilterDefinition is properly exported in bridge_test_exports.rs with a fixture and coverage assertion.

Issues Found

1. Segments not included in view activation (filed as inline comment)

apply_view_default_filters iterates dimensions, time dimensions, measures, and filter members — but not segments. If a query touches a view only through a segment, the view's default filters won't activate. segments is compiled at line 50 of query_properties_compiler.rs but never passed into compile_filters. This may be intentional if segments-only view queries are rare, but it should be documented or fixed.

2. Missing isView guard in prepareViewFilters (filed as inline comment)

The method relies on !cube.filters to skip non-views, which works because Joi strips filters from regular cubes. But adding an explicit cube.isView check would make the contract more robust.

Minor Observations

• YamlCompiler duplication (inline comment): The isViewFilterMember branch duplicates the sql/sqlTable f-string path — could be merged for readability.
• unless between default filters: If view A declares two default filters where filter-2's unless references the same member as filter-1, the unless check uses only user-supplied filters (the mentioned_in_filters set is built before default filters are added). This means default filters can't suppress each other, which seems intentionally correct — unless is a user-override mechanism, not an inter-filter dependency system.
• Validator uses Joi.any().valid(...) for operator: Consistent with existing patterns in the file, but Joi.string().valid(...) would be slightly more precise. Non-blocking.

Test Coverage Summary

Layer	Tests	Scenarios
Validator (TS)	7 tests	Valid filters, set without values, missing values/member, invalid operator, regular cube rejection
Schema (TS)	5 tests	Reference resolution (3 forms), member not included, unless not included, non-included cube path
Rust unit	5 tests	Default applies, unless filter-only, explicit override, unless member absent, unconditional
Rust integration	5 tests	Switch union collapse, unless projection-only, explicit override, unless absent, switch-case measure
Postgres e2e (TS)	6 tests	Real dimension + virtual switch × unconditional/with-unless/explicit-override
Bridge	3 additions	Fixture, coverage assertion, invoke function

Solid work overall. The segments gap is the one functional concern worth addressing before merge.

[claude]

Claude finished @waralexrom's task in 2m 59s —— View job

---

Code Review: feat(tesseract): default value filters for views (CORE-357)

• Gather context and understand PR changes
• Review schema compiler changes (TypeScript)
• Review Rust bridge and planner changes
• Review test coverage
• Review security and edge cases
• Post final review

---

This is a well-structured PR that adds view-level default value filters across the full stack (schema validation → JS evaluator → Rust bridge → Tesseract planner). The implementation is clean, the design decisions are well-reasoned, and the test coverage is thorough. Below are my findings.

---

Architecture & Design

The overall design is sound:

1. Schema validation (CubeValidator.ts) — new ViewFilterSchema with Joi, correctly restricts values requirement based on operator (set/notSet don't need values).
2. Evaluation (CubeEvaluator.ts) — prepareViewFilters() resolves member references against includedMembers, validates membership, coerces values to strings.
3. Rust bridge (view_filter_definition.rs) — clean NativeBridgeStatic struct matching the JS output shape.
4. Planner (query_properties_compiler.rs) — apply_view_default_filters() collects active views from query members, applies filters unless released by unless.

The unless being filter-only (not projection-based) is a deliberate and well-documented design choice that prevents surprising row-count changes when columns are added to the SELECT. Good call.

---

Issues & Suggestions

1. resolveViewMember silently drops resolution on dotted paths (Low Severity)

In CubeEvaluator.ts:238-248, the resolveViewMember function handles three cases: bare name, view-prefixed name, and dotted (cube) path. For the dotted path case (lookupPath), it searches includedMembers by memberPath:

const match = lookupPath
  ? included.find((m) => m.memberPath === lookupPath)
  : included.find((m) => m.name === lookupName);

If a user writes orders.currency (cube-qualified) and the included member's memberPath is also orders.currency, this works fine. But if memberPath uses a different format (e.g., with join paths), the lookup silently fails and falls through to the error reporter. This seems intentional based on the test at schema.test.ts:620 (other.currency → error), but worth confirming that the memberPath format is stable across join paths.

2. Missing negative test for filters on non-view cubes in Rust tests (Nitpick)

The TypeScript validator test at cube-validator.test.ts:329 correctly verifies that a regular (non-view) cube with filters is rejected. However, there's no corresponding test on the Rust side verifying that apply_view_default_filters skips non-view cubes. The code does check is_view at query_properties_compiler.rs:465, but a unit test would improve confidence.

3. ViewFilterSchema operator list doesn't match BaseFilter operators (Observation)

The operator allowlist in CubeValidator.ts:1133-1157 includes all standard operators. This is a superset of what makes semantic sense for a "default value" filter (e.g., inDateRange as a default filter is unusual but technically valid). This seems intentional — no restriction beyond what the filter engine already supports — but worth flagging for documentation purposes.

4. Potential for stale filter_members if add_item modifies existing filters (Low Risk)

In query_properties_compiler.rs:433-436:

let filter_members: Vec<Rc<MemberSymbol>> = filter_compiler
    .iter_all_items()
    .flat_map(|f| f.all_member_evaluators())
    .collect();

The comment correctly notes this is materialized once to avoid borrow conflicts. The mentioned_in_filters set is built before default filters are added. This means default filter A cannot be "unless'd" by default filter B from the same view. This is the correct behavior (only explicit user filters release the guard), and it's well-documented in the comments. Just confirming this is intentional.

5. YamlCompiler special-casing is a bit fragile (Low Severity)

In YamlCompiler.ts:195-200, the isViewFilterMember and isViewFilterUnless regex checks are added inline:

const isViewFilterMember = /^filters\.\d+\.member$/.test(fullPath);
const isViewFilterUnless = /^filters\.\d+\.unless$/.test(fullPath);

These regexes run on every property path for every transpiled field. The performance impact is negligible, but the approach of adding more special-case regexes to this already-complex transpilation loop could become harder to maintain. Not actionable for this PR, but worth noting for future contributors.

---

Test Coverage Assessment

Excellent coverage across all layers:

Layer	Tests	Verdict
Schema validation (Joi)	6 tests: valid filter, valid with unless, set operator, missing values, missing member, invalid operator, non-view cube rejection	Thorough
JS evaluator (CubeEvaluator)	5 tests: reference resolution (short/real-path/view-path), member-not-included error, unless-not-included error, fully-qualified non-included path error, mixed-type value coercion	Thorough
Rust unit tests	5 tests: default applies, unless + projection keeps filter, unless + explicit filter releases, unless member absent, no-unless + projection	Thorough
Rust integration (snapshot)	5 tests with Postgres execution: switch union collapse, unless projection, explicit override, unless member untouched, switch-case measure	Thorough
E2E Postgres	6 tests: real dimension + switch dimension, each with unconditional / unless+projection / unless+explicit filter	Thorough
Bridge coverage	Fixture + fields meta for viewFilterDefinition added	Complete

Edge cases covered:

• Null values in filter values array (coerced correctly)
• Mixed types (numbers, booleans, strings, null) in values
• set/notSet operators without values
• Members referenced by short name, cube-qualified path, and view-qualified path
• Members not included in the view (error)
• Unless references not included in the view (error)

One scenario not explicitly tested: Multiple default filters from the same view where one filter's unless member is also another filter's member. The current code handles this correctly (unless only checks explicit user filters, not other defaults), but an explicit test would document this behavior.

---

Security

No security concerns. The feature:

• Only operates on server-side schema definitions, not user input
• Values are coerced to strings matching the existing FilterItem.values contract
• Member references are validated against includedMembers before reaching the planner
• No SQL injection risk — filters go through the same FilterCompiler path as regular filters

---

Summary

This is a high-quality PR. The implementation is well-layered, the design decisions (especially filter-only unless) are clearly documented with inline comments explaining the why, and the test coverage is comprehensive across all layers. The code is clean and follows existing patterns in both the TypeScript and Rust codebases.

Verdict: Looks good to merge. The issues noted above are low-severity observations rather than blockers.

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.87%. Comparing base (22031fb) to head (b190e34).
⚠️ Report is 17 commits behind head on master.

Files with missing lines	Patch %	Lines
...ubejs-schema-compiler/src/compiler/YamlCompiler.ts	0.00%	6 Missing ⚠️
...bejs-schema-compiler/src/compiler/CubeEvaluator.ts	92.10%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #10892    +/-   ##
========================================
  Coverage   78.86%   78.87%            
========================================
  Files         470      470            
  Lines       92289    92483   +194     
  Branches     3435     3448    +13     
========================================
+ Hits        72788    72948   +160     
- Misses      18999    19031    +32     
- Partials      502      504     +2     

Flag	Coverage Δ
cube-backend	58.44% <80.00%> (+0.07%)	⬆️
cubesql	83.47% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.