Skip to content

Conversation

@ymc9
Copy link
Member

@ymc9 ymc9 commented Nov 26, 2025

Summary by CodeRabbit

  • New Features

    • Added @omit attribute plus client-level omit option with per-query overrides (query > client > schema)
    • Result/payload types now accept client Options so omission settings flow into public typings and hooks
    • Centralized omission resolution used across CRUD paths and SQL dialects
  • Tests

    • Added end-to-end tests, generated schemas and type fixtures covering omission across CRUD, relations, and overrides
  • Chores

    • Bumped pnpm and TypeScript versions

✏️ Tip: You can customize this high-level summary in your review settings.

Copilot AI review requested due to automatic review settings November 26, 2025 23:54
@coderabbitai
Copy link

coderabbitai bot commented Nov 26, 2025

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

Adds an @omit attribute and FieldDef.omit, threads ClientOptions through client contracts and result types, centralizes omission resolution via BaseCrudDialect.shouldOmitField, updates validators and codegen to emit and validate omit, simplifies some client generics to SchemaDef/any, and adds E2E tests and generated omit schema artifacts.

Changes

Cohort / File(s) Summary
Workspace & Tooling
package.json, pnpm-workspace.yaml
Bumped pnpm and workspace TypeScript catalog entry.
Language & Schema
packages/language/res/stdlib.zmodel, packages/schema/src/schema.ts
Added @omit() attribute and omit?: boolean on FieldDef.
Client Options & Types
packages/orm/src/client/options.ts, packages/orm/src/client/contract.ts, packages/orm/src/client/crud-types.ts
Added OmitOptions and omit?: to ClientOptions; introduced Options generic (ClientOptions) across ClientContract, ModelOperations, and result types; added ShouldOmitField and Query/Options/Schema-level omit resolution and threaded Options through result type plumbing.
Client Implementation & Executor
packages/orm/src/client/client-impl.ts, packages/orm/src/client/executor/zenstack-query-executor.ts, packages/orm/src/client/promise.ts
Removed per-schema generics from ClientImpl and ZenStackQueryExecutor (use SchemaDef/any), simplified createZenStackPromise to non-generic, updated signatures and internal casts to SchemaDef/any.
CRUD Runtime & Dialects
packages/orm/src/client/crud/operations/base.ts, packages/orm/src/client/crud/dialects/base-dialect.ts, packages/orm/src/client/crud/dialects/postgresql.ts, packages/orm/src/client/crud/dialects/sqlite.ts
Replaced inline omit checks with dialect.shouldOmitField(...); added shouldOmitField to BaseCrudDialect and updated dialect-specific selection/relation building to consult it.
Validator & Inputs
packages/orm/src/client/crud/validator/index.ts
Find schemas now accept an omit field (validated via makeOmitSchema).
SDK, Codegen & Generated Types
packages/sdk/src/ts-schema-generator.ts, packages/testtools/src/client.ts, generated files under tests/e2e/** and samples/**
ts-schema-generator emits omit: true for fields with @omit, adds $ClientOptions import alias, makes generated ModelGetPayload accept Options; updated many generated GetPayload signatures and test/sample typings; adjusted test client typings.
Client Integrations (TanStack)
packages/clients/tanstack-query/src/{react,svelte,vue}.ts, tests
Propagated ClientOptions<Schema> into SimplifiedModelResult used by query/mutation hooks and mutation result types across React/Svelte/Vue integrations (type-only changes).
Tests & Generated Omit Schema
tests/e2e/orm/client-api/omit.test.ts, tests/e2e/orm/schemas/omit/*
Added E2E tests for omission precedence and generated omit schema artifacts (schema.zmodel, schema.ts, models.ts, input.ts, generated types).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

  • Pay extra attention to:
    • packages/orm/src/client/crud-types.ts — complex recursive type changes and omission-precedence logic.
    • packages/orm/src/client/contract.ts and packages/orm/src/client/client-impl.ts — API surface changes, generics removal, and casts.
    • Dialect/runtime selection code (base-dialect, postgresql.ts, sqlite.ts, operations/base.ts) — runtime behavior must align with type-level omit rules.
    • packages/sdk/src/ts-schema-generator.ts and generated outputs — ensure generated imports and ModelGetPayload signatures are consistent.
    • TanStack integration files — wide-reaching public typing changes across hooks.

Possibly related PRs

Poem

🐇 I nibble at fields, a quiet feat,
A password tucked where types don't meet.
@omit hums soft, Options take their place,
Dialects ask — shall we show its face?
Tests hop by, approving the chase. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'feat(orm): implement field omission' clearly and concisely describes the main change—implementing field omission functionality in the ORM package. It directly reflects the primary objective evident from the comprehensive changes across multiple files.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/omit

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@claude
Copy link

claude bot commented Nov 26, 2025

Claude finished @ymc9's task —— View job


PR Review: Field Omission Implementation ✅

Reviewing the field omission feature implementation across 30 files.

Todo List:

  • Read and understand the core implementation changes
  • Review client contract and CRUD type changes
  • Analyze dialect and database-specific implementations
  • Examine test coverage and test quality
  • Check for potential bugs and edge cases
  • Evaluate performance implications
  • Assess security considerations
  • Provide comprehensive review feedback

Review Summary

This is a well-implemented feature that adds field omission capabilities to ZenStack v3. The implementation is comprehensive, type-safe, and properly tested.

Strengths

1. Clean Architecture & Design

  • Three-level precedence system (query > options > schema) provides excellent flexibility
  • Type-safe implementation with proper TypeScript inference for omitted fields
  • Consistent API across all CRUD operations (create, read, update, delete)

2. Implementation Quality

  • Well-structured code in shouldOmitField() method with clear precedence logic
  • Proper integration across all database dialects (SQLite & PostgreSQL)
  • Schema generation correctly handles @omit attribute in SDK
  • Good separation of concerns between query-level, options-level, and schema-level omission

3. Type Safety

  • Compile-time enforcement - omitted fields correctly show TypeScript errors when accessed
  • Proper type inference for return types based on omit configurations
  • Good use of @ts-expect-error in tests to verify type safety works correctly

4. Test Coverage

  • Comprehensive test suite covering all three omission levels
  • Edge case testing for delegate models, relations, and mixed operations
  • Proper runtime validation that omitted fields are actually undefined
  • Type-level testing ensuring omitted fields show TS errors

🎯 Technical Analysis

Performance Impact:Minimal

  • Field filtering happens at query building time, not during result processing
  • No additional database queries or performance overhead
  • Efficient field selection in SQL generation

Security Considerations:Good

  • Helps protect sensitive fields (passwords, secrets) from accidental exposure
  • Three-level precedence prevents schema-level omissions from being accidentally overridden
  • No security vulnerabilities introduced

Backward Compatibility:Maintained

  • Entirely additive feature - no breaking changes
  • Existing code continues to work unchanged
  • Optional parameters maintain compatibility

🔍 Minor Observations

1. Test Typo (Line 54 in omit.test.ts):

// Missing parentheses
expect(user.password).toBeUndefined; // ❌
expect(user.password).toBeUndefined(); // ✅

2. Potential Enhancement:
The precedence documentation could be clearer in the JSDoc comments explaining the three-level system.

📋 Code Quality Assessment

  • Documentation: Well-documented with clear examples in contract.ts
  • Error Handling: Proper type safety and runtime validation
  • Code Style: Consistent with existing codebase patterns
  • Testing: Excellent coverage including edge cases and type validation

Recommendation: APPROVE

This PR implements a valuable feature with:

  • ✅ Clean, well-structured implementation
  • ✅ Comprehensive type safety
  • ✅ Excellent test coverage
  • ✅ Minimal performance impact
  • ✅ Good security considerations
  • ✅ Backward compatibility maintained

The field omission feature adds significant value for protecting sensitive data while maintaining ZenStack's excellent type safety and developer experience.

Copilot finished reviewing on behalf of ymc9 November 26, 2025 23:56
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR implements comprehensive field omission functionality for ORM query results with three levels of precedence: query-level > client options-level > schema-level. The implementation adds an @omit attribute to the schema language, extends client type definitions to support omission options, and updates all ORM dialects to respect omission rules.

Key changes:

  • Adds @omit attribute to ZModel schema language and FieldDef schema structure
  • Extends ClientContract and ClientOptions with generic Options parameter to track omit configuration at type level
  • Implements three-level omission precedence in type system and runtime
  • Updates TypeScript from 5.8.0 to 5.9.3 (potentially to support new type features)

Reviewed changes

Copilot reviewed 29 out of 30 changed files in this pull request and generated 4 comments.

Show a summary per file
File Description
packages/language/res/stdlib.zmodel Adds @omit attribute definition to schema language
packages/schema/src/schema.ts Adds omit?: boolean field to FieldDef interface
packages/orm/src/client/options.ts Defines OmitOptions type for client-level field omission configuration
packages/orm/src/client/contract.ts Extends ClientContract with Options generic parameter throughout
packages/orm/src/client/crud-types.ts Implements complex type-level omission logic with precedence rules
packages/orm/src/client/crud/dialects/base-dialect.ts Implements shouldOmitField runtime method with precedence logic
packages/orm/src/client/crud/dialects/postgresql.ts Updates relation field selection to respect omit options
packages/orm/src/client/crud/dialects/sqlite.ts Updates relation field selection to respect omit options
packages/orm/src/client/client-impl.ts Removes generic constraints for performance, uses type erasure
packages/testtools/src/client.ts Updates createTestClient signatures to support Options parameter
packages/sdk/src/ts-schema-generator.ts Generates omit field in schema and adds ClientOptions to GetPayload types
tests/e2e/orm/client-api/omit.test.ts Comprehensive test coverage for all omission scenarios
pnpm-workspace.yaml Updates TypeScript version to 5.9.3
Files not reviewed (1)
  • pnpm-lock.yaml: Language not supported

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@claude
Copy link

claude bot commented Nov 26, 2025

Claude finished @ymc9's task —— View job


PR Review: Field Omission Implementation ✅

Reviewing the field omission feature implementation across 30 files.

Todo List:

  • Read and understand the core implementation changes
  • Review client contract and CRUD type changes
  • Analyze dialect and database-specific implementations
  • Examine test coverage and test quality
  • Check for potential bugs and edge cases
  • Evaluate performance implications
  • Assess security considerations
  • Provide comprehensive review feedback

Review Summary

This is a well-implemented feature that adds field omission capabilities to ZenStack v3. The implementation is comprehensive, type-safe, and properly tested.

Strengths

1. Clean Architecture & Design

  • Three-level precedence system (query > options > schema) provides excellent flexibility
  • Type-safe implementation with proper TypeScript inference for omitted fields
  • Consistent API across all CRUD operations (create, read, update, delete)

2. Implementation Quality

  • Well-structured code in shouldOmitField() method with clear precedence logic
  • Proper integration across all database dialects (SQLite & PostgreSQL)
  • Schema generation correctly handles @omit attribute in SDK
  • Good separation of concerns between query-level, options-level, and schema-level omission

3. Type Safety

  • Compile-time enforcement - omitted fields correctly show TypeScript errors when accessed
  • Proper type inference for return types based on omit configurations
  • Good use of @ts-expect-error in tests to verify type safety works correctly

4. Test Coverage

  • Comprehensive test suite covering all three omission levels
  • Edge case testing for delegate models, relations, and mixed operations
  • Proper runtime validation that omitted fields are actually undefined
  • Type-level testing ensuring omitted fields show TS errors

🎯 Technical Analysis

Performance Impact:Minimal

  • Field filtering happens at query building time, not during result processing
  • No additional database queries or performance overhead
  • Efficient field selection in SQL generation

Security Considerations:Good

  • Helps protect sensitive fields (passwords, secrets) from accidental exposure
  • Three-level precedence prevents schema-level omissions from being accidentally overridden
  • No security vulnerabilities introduced

Backward Compatibility:Maintained

  • Entirely additive feature - no breaking changes
  • Existing code continues to work unchanged
  • Optional parameters maintain compatibility

🔍 Minor Observations

1. Test Typo (Line 54 in omit.test.ts):

// Missing parentheses
expect(user.password).toBeUndefined; // ❌
expect(user.password).toBeUndefined(); // ✅

2. Potential Enhancement:
The precedence documentation could be clearer in the JSDoc comments explaining the three-level system.

📋 Code Quality Assessment

  • Documentation: Well-documented with clear examples in contract.ts
  • Error Handling: Proper type safety and runtime validation
  • Code Style: Consistent with existing codebase patterns
  • Testing: Excellent coverage including edge cases and type validation

Recommendation: APPROVE

This PR implements a valuable feature with:

  • ✅ Clean, well-structured implementation
  • ✅ Comprehensive type safety
  • ✅ Excellent test coverage
  • ✅ Minimal performance impact
  • ✅ Good security considerations
  • ✅ Backward compatibility maintained

The field omission feature adds significant value for protecting sensitive data while maintaining ZenStack's excellent type safety and developer experience.


Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (3)
packages/orm/src/client/client-impl.ts (1)

170-189: Double-cast pattern is necessary but consider documenting.

The as unknown as ClientContract<SchemaDef> casts on lines 176 and 186 are necessary due to the class's non-generic design. The actual schema instance is correctly propagated at runtime.

Consider adding a brief inline comment explaining why the double cast is needed, to help future maintainers understand the design decision.

packages/language/res/stdlib.zmodel (1)

396-401: @omit attribute definition aligns with the new ORM omit semantics

The @omit() attribute and its documentation correctly describe default field omission, override via client options or query-time omit, and restriction to ORM query APIs. One optional improvement would be to clarify in the comment whether applying @omit to relation fields is supported or only intended for scalar fields, to avoid ambiguity for schema authors. Also ensure generators that consume stdlib.zmodel have been re-run so the new attribute is reflected in generated TypeScript.

As per coding guidelines, remember to run zenstack generate after modifying .zmodel schemas.

packages/orm/src/client/crud/dialects/base-dialect.ts (1)

872-881: Centralized omit resolution and precedence look good; consider slightly stricter guard

Using shouldOmitField here correctly applies query-level → client-options-level → schema-level precedence and matches the new E2E tests. The implementation is clear and keeps runtime behavior aligned with the new type-level omit model.

If you want to be extra defensive, you could replace the typeof omit === 'object' check with isPlainObject(omit) for the query-level branch to avoid accidentally treating arrays or odd prototypes as omit maps, but that's optional and not required for correctness.

Also applies to: 904-922

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a9922ab and 199642a.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (29)
  • package.json (2 hunks)
  • packages/language/res/stdlib.zmodel (1 hunks)
  • packages/orm/src/client/client-impl.ts (26 hunks)
  • packages/orm/src/client/contract.ts (20 hunks)
  • packages/orm/src/client/crud-types.ts (5 hunks)
  • packages/orm/src/client/crud/dialects/base-dialect.ts (2 hunks)
  • packages/orm/src/client/crud/dialects/postgresql.ts (2 hunks)
  • packages/orm/src/client/crud/dialects/sqlite.ts (1 hunks)
  • packages/orm/src/client/crud/operations/base.ts (1 hunks)
  • packages/orm/src/client/crud/validator/index.ts (1 hunks)
  • packages/orm/src/client/options.ts (3 hunks)
  • packages/orm/src/client/promise.ts (1 hunks)
  • packages/schema/src/schema.ts (1 hunks)
  • packages/sdk/src/ts-schema-generator.ts (4 hunks)
  • packages/testtools/src/client.ts (4 hunks)
  • pnpm-workspace.yaml (1 hunks)
  • tests/e2e/apps/rally/zenstack/input.ts (28 hunks)
  • tests/e2e/orm/client-api/omit.test.ts (1 hunks)
  • tests/e2e/orm/schemas/basic/input.ts (5 hunks)
  • tests/e2e/orm/schemas/default-auth/input.ts (4 hunks)
  • tests/e2e/orm/schemas/delegate/input.ts (8 hunks)
  • tests/e2e/orm/schemas/name-mapping/input.ts (3 hunks)
  • tests/e2e/orm/schemas/omit/input.ts (1 hunks)
  • tests/e2e/orm/schemas/omit/models.ts (1 hunks)
  • tests/e2e/orm/schemas/omit/schema.ts (1 hunks)
  • tests/e2e/orm/schemas/omit/schema.zmodel (1 hunks)
  • tests/e2e/orm/schemas/petstore/input.ts (4 hunks)
  • tests/e2e/orm/schemas/todo/input.ts (6 hunks)
  • tests/e2e/orm/schemas/typing/input.ts (7 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
tests/e2e/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

E2E tests should validate real-world schema compatibility with established projects

Files:

  • tests/e2e/orm/client-api/omit.test.ts
  • tests/e2e/orm/schemas/omit/schema.ts
  • tests/e2e/orm/schemas/name-mapping/input.ts
  • tests/e2e/orm/schemas/todo/input.ts
  • tests/e2e/orm/schemas/omit/models.ts
  • tests/e2e/orm/schemas/basic/input.ts
  • tests/e2e/orm/schemas/petstore/input.ts
  • tests/e2e/orm/schemas/delegate/input.ts
  • tests/e2e/orm/schemas/default-auth/input.ts
  • tests/e2e/orm/schemas/typing/input.ts
  • tests/e2e/apps/rally/zenstack/input.ts
  • tests/e2e/orm/schemas/omit/input.ts
**/*.zmodel

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.zmodel: Always run zenstack generate after modifying ZModel schemas
ZModel schema files should define database structure and policies that compile to TypeScript via zenstack generate

Files:

  • tests/e2e/orm/schemas/omit/schema.zmodel
  • packages/language/res/stdlib.zmodel
🧠 Learnings (9)
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.test.{ts,tsx} : ORM package tests should include comprehensive client API tests and policy tests

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
  • tests/e2e/orm/schemas/omit/schema.ts
  • packages/orm/src/client/crud/operations/base.ts
  • packages/orm/src/client/promise.ts
  • packages/orm/src/client/crud-types.ts
  • tests/e2e/orm/schemas/name-mapping/input.ts
  • packages/orm/src/client/options.ts
  • tests/e2e/orm/schemas/todo/input.ts
  • tests/e2e/orm/schemas/omit/models.ts
  • tests/e2e/orm/schemas/basic/input.ts
  • tests/e2e/orm/schemas/petstore/input.ts
  • tests/e2e/orm/schemas/delegate/input.ts
  • tests/e2e/orm/schemas/default-auth/input.ts
  • packages/orm/src/client/contract.ts
  • tests/e2e/orm/schemas/typing/input.ts
  • packages/orm/src/client/client-impl.ts
  • packages/testtools/src/client.ts
  • tests/e2e/apps/rally/zenstack/input.ts
  • tests/e2e/orm/schemas/omit/input.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to tests/e2e/**/*.{ts,tsx} : E2E tests should validate real-world schema compatibility with established projects

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
  • tests/e2e/orm/schemas/omit/schema.ts
  • tests/e2e/orm/schemas/name-mapping/input.ts
  • tests/e2e/orm/schemas/todo/input.ts
  • tests/e2e/orm/schemas/omit/models.ts
  • tests/e2e/orm/schemas/basic/input.ts
  • tests/e2e/orm/schemas/delegate/input.ts
  • tests/e2e/orm/schemas/default-auth/input.ts
  • packages/testtools/src/client.ts
  • tests/e2e/orm/schemas/omit/input.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.{ts,tsx} : Implement plugin hooks at ORM, Kysely, and entity mutation levels for query interception and customization

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
  • packages/orm/src/client/crud/dialects/base-dialect.ts
  • tests/e2e/orm/schemas/omit/schema.ts
  • packages/orm/src/client/crud/operations/base.ts
  • packages/orm/src/client/crud/dialects/postgresql.ts
  • packages/orm/src/client/promise.ts
  • packages/orm/src/client/crud-types.ts
  • tests/e2e/orm/schemas/name-mapping/input.ts
  • packages/orm/src/client/options.ts
  • tests/e2e/orm/schemas/todo/input.ts
  • tests/e2e/orm/schemas/omit/models.ts
  • tests/e2e/orm/schemas/basic/input.ts
  • tests/e2e/orm/schemas/petstore/input.ts
  • tests/e2e/orm/schemas/delegate/input.ts
  • packages/sdk/src/ts-schema-generator.ts
  • tests/e2e/orm/schemas/default-auth/input.ts
  • packages/orm/src/client/contract.ts
  • tests/e2e/orm/schemas/typing/input.ts
  • packages/orm/src/client/client-impl.ts
  • tests/e2e/apps/rally/zenstack/input.ts
  • tests/e2e/orm/schemas/omit/input.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.{ts,tsx} : Use Kysely as the query builder interface for low-level database queries, avoiding raw SQL when possible

Applied to files:

  • packages/orm/src/client/crud/dialects/base-dialect.ts
  • tests/e2e/orm/schemas/omit/schema.ts
  • packages/orm/src/client/crud/operations/base.ts
  • packages/orm/src/client/crud/dialects/postgresql.ts
  • packages/orm/src/client/promise.ts
  • packages/orm/src/client/crud-types.ts
  • tests/e2e/orm/schemas/name-mapping/input.ts
  • packages/orm/src/client/options.ts
  • tests/e2e/orm/schemas/todo/input.ts
  • tests/e2e/orm/schemas/omit/models.ts
  • tests/e2e/orm/schemas/basic/input.ts
  • tests/e2e/orm/schemas/petstore/input.ts
  • tests/e2e/orm/schemas/delegate/input.ts
  • tests/e2e/orm/schemas/default-auth/input.ts
  • packages/orm/src/client/contract.ts
  • tests/e2e/orm/schemas/typing/input.ts
  • packages/orm/src/client/client-impl.ts
  • tests/e2e/apps/rally/zenstack/input.ts
  • tests/e2e/orm/schemas/omit/input.ts
📚 Learning: 2025-10-21T16:04:56.292Z
Learnt from: ymc9
Repo: zenstackhq/zenstack-v3 PR: 319
File: packages/runtime/src/client/crud/dialects/base-dialect.ts:745-747
Timestamp: 2025-10-21T16:04:56.292Z
Learning: In packages/runtime/src/client/crud/dialects/base-dialect.ts, it's intentional that buildCursorFilter applies default ordering (via makeDefaultOrderBy fallback) while buildOrderBy does not. This ensures cursor-based pagination always has stable ordering for correctness, while regular queries remain unordered unless explicitly specified. This design is to be consistent with Prisma's pagination requirements.

Applied to files:

  • packages/orm/src/client/crud/dialects/base-dialect.ts
  • packages/orm/src/client/crud/operations/base.ts
  • packages/orm/src/client/crud/dialects/postgresql.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to **/*.zmodel : ZModel schema files should define database structure and policies that compile to TypeScript via `zenstack generate`

Applied to files:

  • tests/e2e/orm/schemas/omit/schema.ts
  • packages/orm/src/client/promise.ts
  • tests/e2e/orm/schemas/omit/schema.zmodel
  • tests/e2e/orm/schemas/omit/models.ts
  • packages/sdk/src/ts-schema-generator.ts
  • packages/orm/src/client/contract.ts
  • packages/orm/src/client/client-impl.ts
  • tests/e2e/apps/rally/zenstack/input.ts
  • tests/e2e/orm/schemas/omit/input.ts
📚 Learning: 2025-10-21T16:09:31.218Z
Learnt from: ymc9
Repo: zenstackhq/zenstack-v3 PR: 319
File: packages/runtime/src/client/executor/zenstack-query-executor.ts:63-72
Timestamp: 2025-10-21T16:09:31.218Z
Learning: In ZenStack, TypeDefs can be inherited by models. When a TypeDef contains fields with `map` attributes, those mapped field names need to be processed by the QueryNameMapper since they become part of the inheriting model's schema. Therefore, when checking if a schema has mapped names (e.g., in `schemaHasMappedNames`), both `schema.models` and `schema.typeDefs` must be inspected for `@map` and `map` attributes.

Applied to files:

  • tests/e2e/orm/schemas/omit/schema.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Use `pnpm` with workspaces for package management, pinned to version `pnpm10.12.1`

Applied to files:

  • pnpm-workspace.yaml
  • package.json
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Use Turbo for build orchestration and run `pnpm build`, `pnpm watch`, `pnpm lint`, and `pnpm test` for development tasks

Applied to files:

  • package.json
🧬 Code graph analysis (16)
tests/e2e/orm/client-api/omit.test.ts (4)
packages/testtools/src/client.ts (1)
  • createTestClient (99-248)
packages/orm/src/client/crud/operations/base.ts (3)
  • schema (98-100)
  • options (102-104)
  • read (148-187)
packages/orm/src/client/crud/validator/index.ts (1)
  • schema (60-62)
tests/e2e/orm/schemas/omit/schema.ts (1)
  • schema (141-141)
packages/orm/src/client/crud/dialects/base-dialect.ts (2)
packages/orm/src/client/crud/operations/base.ts (1)
  • requireField (129-131)
packages/orm/src/client/query-utils.ts (1)
  • requireField (45-63)
tests/e2e/orm/schemas/omit/schema.ts (4)
packages/schema/src/expression-utils.ts (1)
  • ExpressionUtils (19-123)
packages/schema/src/schema.ts (1)
  • SchemaDef (11-19)
packages/orm/src/client/crud/operations/base.ts (1)
  • schema (98-100)
packages/orm/src/client/crud/validator/index.ts (1)
  • schema (60-62)
packages/orm/src/client/promise.ts (1)
packages/orm/src/client/contract.ts (1)
  • ClientContract (61-181)
packages/orm/src/client/crud-types.ts (2)
packages/schema/src/schema.ts (11)
  • SchemaDef (11-19)
  • GetModels (121-121)
  • IsDelegateModel (280-283)
  • GetSubModels (127-132)
  • NonRelationFields (205-209)
  • GetModelFields (147-150)
  • GetModelField (152-156)
  • GetModelDiscriminator (158-164)
  • ModelFieldIsOptional (232-236)
  • FieldIsArray (250-254)
  • RelationFieldType (223-230)
packages/orm/src/client/options.ts (1)
  • ClientOptions (45-101)
tests/e2e/orm/schemas/name-mapping/input.ts (8)
tests/e2e/apps/rally/zenstack/input.ts (1)
  • UserGetPayload (50-50)
tests/e2e/orm/schemas/basic/input.ts (2)
  • UserGetPayload (30-30)
  • PostGetPayload (50-50)
tests/e2e/orm/schemas/default-auth/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/delegate/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/omit/input.ts (2)
  • UserGetPayload (30-30)
  • PostGetPayload (50-50)
tests/e2e/orm/schemas/petstore/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/todo/input.ts (1)
  • UserGetPayload (70-70)
tests/e2e/orm/schemas/typing/input.ts (2)
  • UserGetPayload (30-30)
  • PostGetPayload (50-50)
tests/e2e/orm/schemas/todo/input.ts (8)
tests/e2e/apps/rally/zenstack/input.ts (2)
  • SpaceGetPayload (270-270)
  • UserGetPayload (50-50)
tests/e2e/orm/schemas/basic/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/default-auth/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/delegate/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/name-mapping/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/omit/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/petstore/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/typing/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/basic/input.ts (8)
tests/e2e/apps/rally/zenstack/input.ts (2)
  • UserGetPayload (50-50)
  • CommentGetPayload (230-230)
tests/e2e/orm/schemas/default-auth/input.ts (2)
  • UserGetPayload (30-30)
  • ProfileGetPayload (50-50)
tests/e2e/orm/schemas/delegate/input.ts (2)
  • UserGetPayload (30-30)
  • CommentGetPayload (50-50)
tests/e2e/orm/schemas/name-mapping/input.ts (2)
  • UserGetPayload (30-30)
  • PostGetPayload (50-50)
tests/e2e/orm/schemas/omit/input.ts (2)
  • UserGetPayload (30-30)
  • PostGetPayload (50-50)
tests/e2e/orm/schemas/petstore/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/todo/input.ts (1)
  • UserGetPayload (70-70)
tests/e2e/orm/schemas/typing/input.ts (3)
  • UserGetPayload (30-30)
  • PostGetPayload (50-50)
  • ProfileGetPayload (70-70)
tests/e2e/orm/schemas/petstore/input.ts (8)
tests/e2e/apps/rally/zenstack/input.ts (1)
  • UserGetPayload (50-50)
tests/e2e/orm/schemas/basic/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/default-auth/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/delegate/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/name-mapping/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/omit/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/todo/input.ts (1)
  • UserGetPayload (70-70)
tests/e2e/orm/schemas/typing/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/delegate/input.ts (8)
tests/e2e/apps/rally/zenstack/input.ts (2)
  • UserGetPayload (50-50)
  • CommentGetPayload (230-230)
tests/e2e/orm/schemas/basic/input.ts (2)
  • UserGetPayload (30-30)
  • CommentGetPayload (70-70)
tests/e2e/orm/schemas/default-auth/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/name-mapping/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/omit/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/petstore/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/todo/input.ts (1)
  • UserGetPayload (70-70)
tests/e2e/orm/schemas/typing/input.ts (1)
  • UserGetPayload (30-30)
packages/sdk/src/ts-schema-generator.ts (2)
packages/sdk/src/model-utils.ts (1)
  • hasAttribute (59-64)
packages/language/src/utils.ts (1)
  • hasAttribute (55-57)
tests/e2e/orm/schemas/default-auth/input.ts (8)
tests/e2e/apps/rally/zenstack/input.ts (1)
  • UserGetPayload (50-50)
tests/e2e/orm/schemas/basic/input.ts (2)
  • UserGetPayload (30-30)
  • ProfileGetPayload (90-90)
tests/e2e/orm/schemas/delegate/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/name-mapping/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/omit/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/petstore/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/todo/input.ts (1)
  • UserGetPayload (70-70)
tests/e2e/orm/schemas/typing/input.ts (2)
  • UserGetPayload (30-30)
  • ProfileGetPayload (70-70)
packages/orm/src/client/contract.ts (3)
packages/orm/src/client/options.ts (1)
  • ClientOptions (45-101)
packages/orm/src/client/promise.ts (1)
  • ZenStackPromise (7-13)
packages/orm/src/client/crud-types.ts (1)
  • DefaultModelResult (51-75)
packages/testtools/src/client.ts (3)
packages/schema/src/schema.ts (1)
  • SchemaDef (11-19)
packages/orm/src/client/options.ts (1)
  • ClientOptions (45-101)
packages/orm/src/client/contract.ts (1)
  • ClientContract (61-181)
tests/e2e/apps/rally/zenstack/input.ts (7)
tests/e2e/orm/schemas/basic/input.ts (2)
  • UserGetPayload (30-30)
  • CommentGetPayload (70-70)
tests/e2e/orm/schemas/default-auth/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/name-mapping/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/omit/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/petstore/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/todo/input.ts (1)
  • UserGetPayload (70-70)
tests/e2e/orm/schemas/typing/input.ts (1)
  • UserGetPayload (30-30)
tests/e2e/orm/schemas/omit/input.ts (1)
tests/e2e/apps/rally/zenstack/input.ts (20)
  • UserFindManyArgs (31-31)
  • UserFindUniqueArgs (32-32)
  • UserFindFirstArgs (33-33)
  • UserCreateArgs (34-34)
  • UserCreateManyArgs (35-35)
  • UserCreateManyAndReturnArgs (36-36)
  • UserUpdateArgs (37-37)
  • UserUpdateManyArgs (38-38)
  • UserUpdateManyAndReturnArgs (39-39)
  • UserUpsertArgs (40-40)
  • UserDeleteArgs (41-41)
  • UserDeleteManyArgs (42-42)
  • UserCountArgs (43-43)
  • UserAggregateArgs (44-44)
  • UserGroupByArgs (45-45)
  • UserWhereInput (46-46)
  • UserSelect (47-47)
  • UserInclude (48-48)
  • UserOmit (49-49)
  • UserGetPayload (50-50)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Upload results
  • GitHub Check: claude-review
🔇 Additional comments (62)
packages/schema/src/schema.ts (1)

72-72: LGTM!

The omit?: boolean property is well-placed within FieldDef alongside related field metadata. This cleanly supports the schema-level omission feature being introduced.

package.json (2)

5-5: Verify pnpm version alignment with project standards.

The packageManager is set to pnpm@10.23.0, but learnings indicate the project should use pnpm@10.12.1. Please confirm whether this version bump is intentional and if the learnings need to be updated.

Based on learnings, the expected version is pnpm@10.12.1.


28-35: LGTM!

Using catalog: references for prisma and yaml dependencies aligns with the pnpm workspace pattern defined in pnpm-workspace.yaml.

tests/e2e/orm/schemas/basic/input.ts (5)

9-10: LGTM!

The import addition of ClientOptions as $ClientOptions correctly supports the new Options generic parameter in GetPayload types.


30-30: LGTM!

The UserGetPayload signature update to include the Options generic parameter with a sensible default is consistent with the pattern across other test schemas (petstore, todo, omit, delegate, etc.) and aligns with the broader Options-aware typing introduced in this PR.


50-50: Consistent with PR pattern.

PostGetPayload signature follows the same Options-aware pattern.


70-70: Consistent with PR pattern.

CommentGetPayload signature follows the same Options-aware pattern.


90-90: Consistent with PR pattern.

ProfileGetPayload signature follows the same Options-aware pattern. As per coding guidelines, E2E tests should validate real-world schema compatibility, and these generated types enable that validation.

packages/orm/src/client/client-impl.ts (7)

46-52: LGTM on ZenStackClient factory.

The factory correctly casts options to ClientOptions<SchemaDef> to work with the non-generic ClientImpl class. This maintains the public API's type safety while allowing internal simplification.


54-67: Intentional simplification for tsc performance.

The removal of the Schema generic parameter from ClientImpl in favor of SchemaDef is a deliberate architectural decision. Type safety is preserved at the public API boundary through ZenStackClient factory and ClientContract<Schema> types.


140-149: LGTM on transaction overloads.

The transaction overloads are correctly updated to use SchemaDef-based contract types, maintaining consistency with the non-generic class design.


255-287: LGTM on plugin methods.

The explicit typing of newPlugins and newOptions with RuntimePlugin<SchemaDef>[] and ClientOptions<SchemaDef> respectively improves code clarity while supporting the tsc performance optimization mentioned in comments.


368-373: Intentional any-typing for tsc performance.

The use of any for type parameters in createModelCrudHandler is a deliberate trade-off for TypeScript compilation performance, as noted in the comment on line 421. Runtime safety is maintained through InputValidator and the public API boundary preserves full type safety.


422-594: Consistent any-typing across operation handlers.

All operation handler instantiations (FindOperationHandler<any>, CreateOperationHandler<any>, etc.) follow the same pattern, which is appropriate given the performance optimization goal. The explicit as ModelOperations<any, any> cast on line 594 makes the trade-off visible.


346-366: LGTM on createClientProxy simplification.

The non-generic function correctly bridges the ClientImpl instance to the generic InputValidator and model CRUD handlers through necessary any casts, maintaining the proxy pattern while supporting the simplified class design.

pnpm-workspace.yaml (1)

12-12: TypeScript 5.9.3 is a valid and released version.

The version is published on npm and was released on October 1, 2025. The bump from ^5.8.0 to ^5.9.3 is supported by legitimate new features in TypeScript 5.9, making this dependency upgrade appropriate for the PR's expanded generics and Options-based typing changes.

tests/e2e/apps/rally/zenstack/input.ts (1)

9-10: Options-aware GetPayload typings look consistent and safe

The added ClientOptions as $ClientOptions import and the new Options extends $ClientOptions<$Schema> = $ClientOptions<$Schema> parameter threaded into all *GetPayload aliases are consistent with other schemas and keep existing call sites working via the default. No issues from a typing or behavior standpoint.

Also applies to: 30-550

packages/orm/src/client/crud/dialects/postgresql.ts (1)

15-15: Centralized omit handling and error reporting are correct here

Using this.shouldOmitField(omit, relationModel, name) when selecting scalar relation fields correctly delegates omit resolution to the shared dialect helper, so schema/options/query-level omit are applied consistently. The new createInternalError usage in getFieldSqlType for relation fields also tightens error reporting without changing behavior.

Also applies to: 307-317, 441-443

packages/orm/src/client/crud/dialects/sqlite.ts (1)

200-207: SQLite relation scalar omission wired through shouldOmitField correctly

In the payload === true || !payload.select branch, deriving omit from payload.omit and filtering scalar fields with !this.shouldOmitField(omit, relationModel, name) cleanly reuses the shared omit resolution. This keeps SQLite behavior aligned with PostgreSQL and the base dialect.

packages/orm/src/client/crud/validator/index.ts (1)

260-293: Omit support in input validation is well-integrated

The new validation rules for omit look coherent:

  • makeFindSchema adds omit and refines so select cannot be combined with omit, while still allowing include+omit.
  • Relation selection (makeRelationSelectIncludeSchema) now supports nested omit with the same select vs omit exclusivity.
  • makeOmitSchema restricting omit to non-relation fields matches the runtime’s scalar-only omit behavior.
  • Create/Update/Upsert/Delete schemas all accept omit and are guarded by refineForSelectOmitMutuallyExclusive, keeping the API surface consistent.

Overall this aligns the Zod layer with the new omit semantics threaded through the client.

Also applies to: 740-790, 872-883, 889-896, 1150-1193, 1301-1309, 1516-1521

packages/orm/src/client/crud/operations/base.ts (1)

2147-2163: Read-back decision now respects omit configuration

The updated mutationNeedsReadBack correctly excludes fields that this.dialect.shouldOmitField(args.omit, model, f) marks as omitted, both in the implicit “all scalars” case and the explicit select case. That means omitted fields no longer force unnecessary read-backs nor get treated as part of the selected scalar set, while relation/computed-field detection remains intact.

tests/e2e/orm/schemas/omit/models.ts (1)

1-13: Generated ModelResult aliases are correct

The new User, Post, Base, and Sub aliases to $ModelResult<$Schema, "..."> are straightforward and consistent with other schema fixtures, and will pick up the default Options generic from ModelResult. No changes needed here.

tests/e2e/orm/schemas/omit/schema.ts (1)

8-137: Generated schema correctly reflects @omit and delegate structure

The generated schema mirrors the zmodel: User.password and Sub.content are marked with omit: true and have @omit in attributes, and delegate metadata for Base/Sub looks consistent. This should work well with shouldOmitField and the new omit pipeline.

packages/orm/src/client/options.ts (1)

45-101: Client-level OmitOptions wiring is consistent with dialect omit logic

Threading omit?: OmitOptions<Schema> through ClientOptions and constraining it to scalar fields via ScalarFields<Schema, Model> aligns with how BaseCrudDialect.shouldOmitField reads this.options.omit. This should give good type safety for client-level omit configuration without affecting relation handling.

Also applies to: 103-110

packages/sdk/src/ts-schema-generator.ts (1)

554-556: @omit schema emission and Options-aware GetPayload generation are consistent

Adding omit: true when a field has @omit in createDataFieldObject correctly surfaces schema-level omission for the runtime (and matches the generated omit schema). The updated input-type generation—importing ClientOptions as $ClientOptions and defining ModelGetPayload with an Options type parameter passed into $SimplifiedModelResult—aligns with the new Options-threaded payload model used elsewhere.

This should keep generated schemas and input types in sync with the central omit and options behavior.

Also applies to: 1557-1571, 1619-1650

tests/e2e/orm/schemas/name-mapping/input.ts (1)

9-10: Name-mapping GetPayload types now correctly parameterized by Options

Importing ClientOptions as $ClientOptions and updating UserGetPayload / PostGetPayload to take an Options extends $ClientOptions<$Schema> = $ClientOptions<$Schema> parameter keeps these generated types consistent with the rest of the schemas using $SimplifiedModelResult<$Schema, Model, Options, Args>.

Also applies to: 30-30, 50-50

tests/e2e/orm/schemas/omit/schema.zmodel (1)

1-29: Omit-focused test schema looks correct; ensure generators stay in sync

The zmodel cleanly exercises @omit on User.password and Sub.content, plus a simple delegate hierarchy for Base/Sub, which matches the generated schema.ts you added.

Per the project guidelines, just make sure zenstack generate has been (and will be) re-run whenever this schema changes so the generated TS artifacts remain consistent.

tests/e2e/orm/schemas/petstore/input.ts (1)

9-10: Auto-generated types correctly updated for Options threading.

The GetPayload types for User, Pet, and Order now correctly include the Options generic parameter with proper defaults, and the import of ClientOptions is added. The pattern is consistent with other generated files in the codebase.

Also applies to: 30-30, 50-50, 70-70

tests/e2e/orm/schemas/todo/input.ts (1)

9-10: Auto-generated types correctly updated for all models.

All five GetPayload types (Space, SpaceUser, User, List, Todo) are updated with the Options generic parameter following the consistent pattern across the codebase.

Also applies to: 30-30, 50-50, 70-70, 90-90, 110-110

tests/e2e/orm/schemas/typing/input.ts (1)

9-10: Auto-generated types correctly updated for all models.

All six GetPayload types (User, Post, Profile, Tag, Region, Meta) are updated with the Options generic parameter, consistent with the PR-wide pattern.

Also applies to: 30-30, 50-50, 70-70, 90-90, 110-110, 130-130

tests/e2e/orm/schemas/delegate/input.ts (1)

9-10: Auto-generated types correctly updated for all models including delegate hierarchy.

All seven GetPayload types (User, Comment, Asset, Video, RatedVideo, Image, Gallery) are updated with the Options generic parameter. This correctly covers the delegate model hierarchy (Asset with Video/RatedVideo/Image subtypes).

Also applies to: 30-30, 50-50, 70-70, 90-90, 110-110, 130-130, 150-150

packages/orm/src/client/crud-types.ts (4)

77-116: Well-designed omit precedence system.

The three-level omit resolution (query → options → schema) is cleanly implemented:

  • Each level returns undefined when not specified, allowing fallthrough to the next level
  • SchemaLevelOmit is the terminal case, always returning true or false
  • The extends boolean check correctly distinguishes explicit true/false from undefined

51-75: Options threading in DefaultModelResult and DelegateUnionResult is correct.

The Options generic is properly threaded through both types, and ShouldOmitField is correctly applied to filter non-relation fields based on the multi-level omit precedence.

Also applies to: 117-125


127-180: ModelSelectResult correctly threads Options to nested relations.

The Options parameter is properly passed to nested ModelResult and DefaultModelResult calls for relation fields, enabling consistent omit behavior across nested query results.


240-247: SimplifiedModelResult requires explicit Options parameter.

The SimplifiedModelResult type requires Options without a default, which is intentional. The generated GetPayload types provide the default (Options extends $ClientOptions<$Schema> = $ClientOptions<$Schema>), ensuring type safety at the call site while allowing flexibility for explicit option customization.

tests/e2e/orm/schemas/default-auth/input.ts (4)

9-10: LGTM!

The ClientOptions import and its usage in the GetPayload types are correctly added, aligning with the new Options-aware type system for field omission support.


30-30: Consistent with the Options threading pattern.

The UserGetPayload type signature with the new Options generic parameter matches the pattern used across other generated files (e.g., tests/e2e/apps/rally/zenstack/input.ts, tests/e2e/orm/schemas/basic/input.ts).


50-50: ProfileGetPayload signature is correct.


70-70: AddressGetPayload signature is correct.

packages/testtools/src/client.ts (7)

35-88: Clean extraction of test-specific options.

Separating ExtraTestClientOptions from ClientOptions improves clarity and maintainability. The type structure is well-documented with JSDoc comments.


90-91: Type composition looks correct.

CreateTestClientOptions properly combines client options (minus dialect) with extra test options.


99-102: Implementation signature correctly uses SchemaDef.

Using SchemaDef as the base type in the implementation is appropriate since it handles both the typed schema object and string-parsed schema cases.


104-104: Variable renamed to _schema: SchemaDef.

Consistent with the updated generic approach.


125-125: Cast to SchemaDef is appropriate.

The generated schema from string parsing needs to be cast since the generator returns a generic schema object.


155-157: Destructuring excludes plugins correctly.

The plugins are handled separately and not passed directly to the client options. The rest spread includes extra test options, but since ZenStackClient will ignore unknown properties, this is acceptable.


93-98: I'll help you verify the overload type inference and the filtering of ExtraTestClientOptions properties. Let me start by examining the relevant code sections.
<function_calls>

#!/bin/bash

First, let's view the lines around 155-157 to see how _options is constructed

wc -l packages/testtools/src/client.ts


</function_calls>

Looking at the file size first, then I'll examine the specific lines mentioned in the review comment.
<function_calls>

#!/bin/bash

View lines 150-165 to see the _options construction

sed -n '150,165p' packages/testtools/src/client.ts


</function_calls>

Now let me search for the ExtraTestClientOptions definition and understand the filtering logic:
<function_calls>

#!/bin/bash

Search for ExtraTestClientOptions definition

rg -n "ExtraTestClientOptions" packages/testtools/src/client.ts -A 5 -B 2


</function_calls>

Let me also view the complete context of lines 93-98 and the function implementation:
<function_calls>

#!/bin/bash

View lines 85-110 to see overloads and function start

sed -n '85,110p' packages/testtools/src/client.ts


</function_calls>

<function_calls>

#!/bin/bash

Let's look at the createTestClientOptions type definition

rg -n "CreateTestClientOptions" packages/testtools/src/client.ts -A 5 -B 2


</function_calls>

<function_calls>

#!/bin/bash

Check the complete function implementation from line 99 onwards

sed -n '99,180p' packages/testtools/src/client.ts


</function_calls>

packages/orm/src/client/contract.ts (11)

61-67: Options generic properly threaded through ClientContract.

The Options parameter with its default ClientOptions<Schema> maintains backward compatibility while enabling Options-aware result types. The $options property correctly uses the Options type.


115-121: Methods returning new clients preserve Options.

$setAuth and $setInputValidation correctly return ClientContract<Schema, Options> to maintain type consistency across client transformations.


136-139: Transaction callback type updated correctly.

The transaction callback receives a client with the same Options type, ensuring omit behavior is consistent within transactions.


152-162: Plugin methods preserve Options type.

$use, $unuse, and $unuseAll correctly return clients with the same Options type.


180-181: Model operations mapped with Options.

The intersection type correctly passes Options to ModelOperations, enabling Options-aware result types for all model operations.


186-189: TransactionClientContract properly parameterized.

Consistent with the main ClientContract signature.


230-234: ClientConstructor signature updated.

The constructor correctly accepts and propagates the Options type parameter.


258-262: AllModelOperations now Options-aware.

This enables all CRUD operations to return properly typed results with omit support.


344-346: findMany return type includes Options.

SimplifiedModelResult<Schema, Model, Options, T> ensures omit configuration is reflected in the result type.


819-827: ModelOperations delegates to AllModelOperations with Options.

The Omit wrapper correctly handles delegate model exclusions while preserving the Options parameter.


837-843: AuthModelType intentionally uses default ClientOptions.

Using ClientOptions<Schema> without the custom Options parameter for auth context is correct—auth data should not be affected by user-configured omit options since it's used internally for authorization checks.

tests/e2e/orm/schemas/omit/input.ts (5)

1-10: Auto-generated file with correct structure.

The file follows the standard generated input pattern with proper imports including ClientOptions for Options-aware types.


11-30: User model types correctly generated.

All CRUD operation types and the UserGetPayload with Options parameter are consistent with the omit feature implementation.


31-50: Post model types correctly generated.


51-70: Base model types correctly generated.

Including delegate model support for the omit schema tests.


71-90: Sub model types correctly generated.

The Sub model (inheriting from Base) is properly typed for testing omit behavior with model inheritance. As per coding guidelines, this E2E test schema validates real-world schema compatibility with the new omit feature.

@claude
Copy link

claude bot commented Nov 27, 2025

Claude finished @ymc9's task —— View job


PR Review: Field Omission Implementation ✅

Reviewing the field omission feature implementation across 30 files.

Todo List:

  • Read and understand the core implementation changes
  • Review client contract and CRUD type changes
  • Analyze dialect and database-specific implementations
  • Examine test coverage and test quality
  • Check for potential bugs and edge cases
  • Evaluate performance implications
  • Assess security considerations
  • Provide comprehensive review feedback

Review Summary

This is a well-implemented feature that adds field omission capabilities to ZenStack v3. The implementation is comprehensive, type-safe, and properly tested.

Strengths

1. Clean Architecture & Design

  • Three-level precedence system (query > options > schema) provides excellent flexibility
  • Type-safe implementation with proper TypeScript inference for omitted fields
  • Consistent API across all CRUD operations (create, read, update, delete)

2. Implementation Quality

  • Well-structured code in shouldOmitField() method with clear precedence logic
  • Proper integration across all database dialects (SQLite & PostgreSQL)
  • Schema generation correctly handles @omit attribute in SDK
  • Good separation of concerns between query-level, options-level, and schema-level omission

3. Type Safety

  • Compile-time enforcement - omitted fields correctly show TypeScript errors when accessed
  • Proper type inference for return types based on omit configurations
  • Good use of @ts-expect-error in tests to verify type safety works correctly

4. Test Coverage

  • Comprehensive test suite covering all three omission levels
  • Edge case testing for delegate models, relations, and mixed operations
  • Proper runtime validation that omitted fields are actually undefined
  • Type-level testing ensuring omitted fields show TS errors

🎯 Technical Analysis

Performance Impact:Minimal

  • Field filtering happens at query building time, not during result processing
  • No additional database queries or performance overhead
  • Efficient field selection in SQL generation

Security Considerations:Good

  • Helps protect sensitive fields (passwords, secrets) from accidental exposure
  • Three-level precedence prevents schema-level omissions from being accidentally overridden
  • No security vulnerabilities introduced

Backward Compatibility:Maintained

  • Entirely additive feature - no breaking changes
  • Existing code continues to work unchanged
  • Optional parameters maintain compatibility

🔍 Minor Observations

1. Test Typo (Line 54 in omit.test.ts):

// Missing parentheses
expect(user.password).toBeUndefined; // ❌
expect(user.password).toBeUndefined(); // ✅

2. Potential Enhancement:
The precedence documentation could be clearer in the JSDoc comments explaining the three-level system.

📋 Code Quality Assessment

  • Documentation: Well-documented with clear examples in contract.ts
  • Error Handling: Proper type safety and runtime validation
  • Code Style: Consistent with existing codebase patterns
  • Testing: Excellent coverage including edge cases and type validation

Recommendation: APPROVE

This PR implements a valuable feature with:

  • ✅ Clean, well-structured implementation
  • ✅ Comprehensive type safety
  • ✅ Excellent test coverage
  • ✅ Minimal performance impact
  • ✅ Good security considerations
  • ✅ Backward compatibility maintained

The field omission feature adds significant value for protecting sensitive data while maintaining ZenStack's excellent type safety and developer experience.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

♻️ Duplicate comments (1)
tests/e2e/orm/client-api/omit.test.ts (1)

39-77: LGTM!

The test correctly validates client-level omit configuration and precedence rules. Line 54's assertion is properly invoked with toBeUndefined(), resolving the past review concern.

🧹 Nitpick comments (1)
tests/e2e/orm/client-api/omit.test.ts (1)

5-139: Consider adding tests for batch operations and additional finder methods.

The current test coverage is solid. To further strengthen the E2E validation, consider adding tests for:

  • Batch operations: createMany, updateMany, deleteMany with omit behavior
  • Additional finders: findMany, findUnique, findUniqueOrThrow with omit configurations
  • Aggregation operations if omit should affect those

This aligns with the guideline that E2E tests should validate real-world compatibility, and batch operations are common in production scenarios.

Based on learnings, ORM package tests should include comprehensive client API tests.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 199642a and c19e7e4.

📒 Files selected for processing (1)
  • tests/e2e/orm/client-api/omit.test.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
tests/e2e/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

E2E tests should validate real-world schema compatibility with established projects

Files:

  • tests/e2e/orm/client-api/omit.test.ts
🧠 Learnings (3)
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.test.{ts,tsx} : ORM package tests should include comprehensive client API tests and policy tests

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to tests/e2e/**/*.{ts,tsx} : E2E tests should validate real-world schema compatibility with established projects

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.{ts,tsx} : Implement plugin hooks at ORM, Kysely, and entity mutation levels for query interception and customization

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
🔇 Additional comments (4)
tests/e2e/orm/client-api/omit.test.ts (4)

1-3: LGTM!

The imports are appropriate for an E2E test validating field omission functionality.


6-37: LGTM!

The test comprehensively validates schema-level omit across all major CRUD operations (create, read, update, delete) and nested relations. All assertions are correctly invoked.


79-122: LGTM!

The test thoroughly validates query-level omit precedence and override behavior across all CRUD operations and nested relations. The use of different IDs (1 and 2) properly avoids potential conflicts.


124-138: LGTM!

The test correctly validates that field omission works with delegate model patterns, including proper override behavior.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
packages/orm/src/client/executor/zenstack-query-executor.ts (1)

356-377: Consider removing the redundant as string cast.

All match branches either return string (identifier names) or throw an error (returning never). TypeScript should infer the return type as string without the explicit cast. If ts-pattern type inference requires it, consider adding a brief comment explaining why.

             .otherwise((node) => {
                 throw createInternalError(`Invalid query node: ${node}`);
-            }) as string;
+            });
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c19e7e4 and b42f42d.

📒 Files selected for processing (1)
  • packages/orm/src/client/executor/zenstack-query-executor.ts (11 hunks)
🧰 Additional context used
🧠 Learnings (5)
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.{ts,tsx} : Implement plugin hooks at ORM, Kysely, and entity mutation levels for query interception and customization

Applied to files:

  • packages/orm/src/client/executor/zenstack-query-executor.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.{ts,tsx} : Use Kysely as the query builder interface for low-level database queries, avoiding raw SQL when possible

Applied to files:

  • packages/orm/src/client/executor/zenstack-query-executor.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to **/*.zmodel : ZModel schema files should define database structure and policies that compile to TypeScript via `zenstack generate`

Applied to files:

  • packages/orm/src/client/executor/zenstack-query-executor.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.test.{ts,tsx} : ORM package tests should include comprehensive client API tests and policy tests

Applied to files:

  • packages/orm/src/client/executor/zenstack-query-executor.ts
📚 Learning: 2025-10-21T16:09:31.218Z
Learnt from: ymc9
Repo: zenstackhq/zenstack-v3 PR: 319
File: packages/runtime/src/client/executor/zenstack-query-executor.ts:63-72
Timestamp: 2025-10-21T16:09:31.218Z
Learning: In ZenStack, TypeDefs can be inherited by models. When a TypeDef contains fields with `map` attributes, those mapped field names need to be processed by the QueryNameMapper since they become part of the inheriting model's schema. Therefore, when checking if a schema has mapped names (e.g., in `schemaHasMappedNames`), both `schema.models` and `schema.typeDefs` must be inspected for `@map` and `map` attributes.

Applied to files:

  • packages/orm/src/client/executor/zenstack-query-executor.ts
🧬 Code graph analysis (1)
packages/orm/src/client/executor/zenstack-query-executor.ts (3)
packages/orm/src/client/executor/name-mapper.ts (1)
  • QueryNameMapper (48-719)
packages/schema/src/schema.ts (1)
  • SchemaDef (11-19)
packages/orm/src/client/contract.ts (1)
  • ClientContract (61-181)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: claude-review
🔇 Additional comments (6)
packages/orm/src/client/executor/zenstack-query-executor.ts (6)

27-42: LGTM!

The import and type changes align well with the architectural shift from generic parameterization to concrete SchemaDef-based types. The MutationInfo type is appropriately simplified to use string-based model identifiers.


44-64: LGTM!

The class declaration and constructor changes correctly remove the generic parameter while preserving the initialization logic. The schemaHasMappedNames check continues to work correctly with client.$schema.


66-75: LGTM!

The method correctly inspects both schema.models and schema.typeDefs for mapped names, which is important since TypeDefs can be inherited by models and their mapped field names need processing. Based on learnings, this pattern is correct.


137-156: LGTM!

The hook type and client cast changes are consistent with the non-generic architecture. The double cast (as unknown as ClientContract<SchemaDef>) is a necessary workaround given that ClientImpl is now non-generic while ClientContract still expects a schema type parameter.


379-457: LGTM!

The mutation hook methods (callBeforeMutationHooks and callAfterMutationHooks) are consistently updated to use SchemaDef-based types. The hook invocation logic and callback handling remain functionally correct.


459-475: LGTM!

The loadEntities method correctly accepts a string model name and uses it with Kysely's selectFrom. The change from strongly-typed GetModels<Schema> to string aligns with the broader architectural shift in this PR.

@claude
Copy link

claude bot commented Nov 27, 2025

Claude finished @ymc9's task —— View job


PR Review: Field Omission Implementation ✅

Reviewing the field omission feature implementation across 30 files.

Todo List:

  • Read and understand the core implementation changes
  • Review client contract and CRUD type changes
  • Analyze dialect and database-specific implementations
  • Examine test coverage and test quality
  • Check for potential bugs and edge cases
  • Evaluate performance implications
  • Assess security considerations
  • Provide comprehensive review feedback

Review Summary

This is a well-implemented feature that adds field omission capabilities to ZenStack v3. The implementation is comprehensive, type-safe, and properly tested.

Strengths

1. Clean Architecture & Design

  • Three-level precedence system (query > options > schema) provides excellent flexibility
  • Type-safe implementation with proper TypeScript inference for omitted fields
  • Consistent API across all CRUD operations (create, read, update, delete)

2. Implementation Quality

  • Well-structured code in shouldOmitField() method with clear precedence logic
  • Proper integration across all database dialects (SQLite & PostgreSQL)
  • Schema generation correctly handles @omit attribute in SDK
  • Good separation of concerns between query-level, options-level, and schema-level omission

3. Type Safety

  • Compile-time enforcement - omitted fields correctly show TypeScript errors when accessed
  • Proper type inference for return types based on omit configurations
  • Good use of @ts-expect-error in tests to verify type safety works correctly

4. Test Coverage

  • Comprehensive test suite covering all three omission levels
  • Edge case testing for delegate models, relations, and mixed operations
  • Proper runtime validation that omitted fields are actually undefined
  • Type-level testing ensuring omitted fields show TS errors

🎯 Technical Analysis

Performance Impact:Minimal

  • Field filtering happens at query building time, not during result processing
  • No additional database queries or performance overhead
  • Efficient field selection in SQL generation

Security Considerations:Good

  • Helps protect sensitive fields (passwords, secrets) from accidental exposure
  • Three-level precedence prevents schema-level omissions from being accidentally overridden
  • No security vulnerabilities introduced

Backward Compatibility:Maintained

  • Entirely additive feature - no breaking changes
  • Existing code continues to work unchanged
  • Optional parameters maintain compatibility

🔍 Minor Observations

1. Test Typo (Line 54 in omit.test.ts):

// Missing parentheses
expect(user.password).toBeUndefined; // ❌
expect(user.password).toBeUndefined(); // ✅

2. Potential Enhancement:
The precedence documentation could be clearer in the JSDoc comments explaining the three-level system.

📋 Code Quality Assessment

  • Documentation: Well-documented with clear examples in contract.ts
  • Error Handling: Proper type safety and runtime validation
  • Code Style: Consistent with existing codebase patterns
  • Testing: Excellent coverage including edge cases and type validation

Recommendation: APPROVE

This PR implements a valuable feature with:

  • ✅ Clean, well-structured implementation
  • ✅ Comprehensive type safety
  • ✅ Excellent test coverage
  • ✅ Minimal performance impact
  • ✅ Good security considerations
  • ✅ Backward compatibility maintained

The field omission feature adds significant value for protecting sensitive data while maintaining ZenStack's excellent type safety and developer experience.


@claude
Copy link

claude bot commented Nov 27, 2025

Claude Code is working…

I'll analyze this and get back to you.

View job run

@claude
Copy link

claude bot commented Nov 27, 2025

Claude finished @ymc9's task —— View job


PR Review: Field Omission Implementation ✅

Reviewing the field omission feature implementation across 30 files.

Todo List:

  • Read and understand the core implementation changes
  • Review client contract and CRUD type changes
  • Analyze dialect and database-specific implementations
  • Examine test coverage and test quality
  • Check for potential bugs and edge cases
  • Evaluate performance implications
  • Assess security considerations
  • Provide comprehensive review feedback

Review Summary

This is a well-implemented feature that adds field omission capabilities to ZenStack v3. The implementation is comprehensive, type-safe, and properly tested.

Strengths

1. Clean Architecture & Design

  • Three-level precedence system (query > options > schema) provides excellent flexibility
  • Type-safe implementation with proper TypeScript inference for omitted fields
  • Consistent API across all CRUD operations (create, read, update, delete)

2. Implementation Quality

  • Well-structured code in shouldOmitField() method with clear precedence logic
  • Proper integration across all database dialects (SQLite & PostgreSQL)
  • Schema generation correctly handles @omit attribute in SDK
  • Good separation of concerns between query-level, options-level, and schema-level omission

3. Type Safety

  • Compile-time enforcement - omitted fields correctly show TypeScript errors when accessed
  • Proper type inference for return types based on omit configurations
  • Good use of @ts-expect-error in tests to verify type safety works correctly

4. Test Coverage

  • Comprehensive test suite covering all three omission levels
  • Edge case testing for delegate models, relations, and mixed operations
  • Proper runtime validation that omitted fields are actually undefined
  • Type-level testing ensuring omitted fields show TS errors

🎯 Technical Analysis

Performance Impact:Minimal

  • Field filtering happens at query building time, not during result processing
  • No additional database queries or performance overhead
  • Efficient field selection in SQL generation

Security Considerations:Good

  • Helps protect sensitive fields (passwords, secrets) from accidental exposure
  • Three-level precedence prevents schema-level omissions from being accidentally overridden
  • No security vulnerabilities introduced

Backward Compatibility:Maintained

  • Entirely additive feature - no breaking changes
  • Existing code continues to work unchanged
  • Optional parameters maintain compatibility

🔍 Minor Observations

1. Test Typo (Line 54 in omit.test.ts):

// Missing parentheses
expect(user.password).toBeUndefined; // ❌
expect(user.password).toBeUndefined(); // ✅

2. Potential Enhancement:
The precedence documentation could be clearer in the JSDoc comments explaining the three-level system.

📋 Code Quality Assessment

  • Documentation: Well-documented with clear examples in contract.ts
  • Error Handling: Proper type safety and runtime validation
  • Code Style: Consistent with existing codebase patterns
  • Testing: Excellent coverage including edge cases and type validation

Recommendation: APPROVE

This PR implements a valuable feature with:

  • ✅ Clean, well-structured implementation
  • ✅ Comprehensive type safety
  • ✅ Excellent test coverage
  • ✅ Minimal performance impact
  • ✅ Good security considerations
  • ✅ Backward compatibility maintained

The field omission feature adds significant value for protecting sensitive data while maintaining ZenStack's excellent type safety and developer experience.


@claude
Copy link

claude bot commented Nov 27, 2025

Claude finished @ymc9's task —— View job


I'll analyze this and get back to you.

@claude
Copy link

claude bot commented Nov 27, 2025

Claude finished @ymc9's task —— View job


I'll analyze this and get back to you.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
tests/e2e/orm/client-api/omit.test.ts (1)

67-79: Minor naming and assertion-strength nits in override tests

Two small optional tweaks:

  • The names 'allows override at query options level' (Lines 67–79) vs 'allows override at query level' (Lines 115–126) are quite similar; consider renaming to make the distinction between “client options override” and “per-query override” immediately clear.
  • Where you currently use toBeTruthy() to assert fields are not omitted (e.g., Lines 78–79, 87–88, 90–91, 106–107, 109–110, 112–113, 125–126, 141–142), you could use more explicit matchers like toBe('abc') or toBe('Foo') if you want stricter guarantees about the returned values, not just their presence.

Current code is fine; these are purely readability/strictness improvements.

Also applies to: 81-113, 115-126, 128-142

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6a80985 and 5bdbbd3.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (2)
  • samples/next.js/package.json (1 hunks)
  • tests/e2e/orm/client-api/omit.test.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
tests/e2e/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

E2E tests should validate real-world schema compatibility with established projects

Files:

  • tests/e2e/orm/client-api/omit.test.ts
🧠 Learnings (3)
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to tests/e2e/**/*.{ts,tsx} : E2E tests should validate real-world schema compatibility with established projects

Applied to files:

  • samples/next.js/package.json
  • tests/e2e/orm/client-api/omit.test.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.test.{ts,tsx} : ORM package tests should include comprehensive client API tests and policy tests

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
📚 Learning: 2025-11-26T01:55:04.529Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.529Z
Learning: Applies to packages/zenstackhq/orm/**/*.{ts,tsx} : Implement plugin hooks at ORM, Kysely, and entity mutation levels for query interception and customization

Applied to files:

  • tests/e2e/orm/client-api/omit.test.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: build-test (20.x, sqlite)
  • GitHub Check: build-test (20.x, postgresql)
  • GitHub Check: claude-review
🔇 Additional comments (2)
samples/next.js/package.json (1)

35-35: Aligns with monorepo version management.

Updating TypeScript to use the catalog-based version ensures consistency with other dependencies in the workspace and reduces the risk of version mismatches across packages.

tests/e2e/orm/client-api/omit.test.ts (1)

5-143: Comprehensive E2E coverage of omit semantics across layers

This suite does a solid job exercising omit at schema, client options, and query levels across create/read/update/delete, nested includes, and delegate models, with @ts-expect-error ensuring type-level omission as well. This aligns well with the guideline that E2E tests validate realistic schema usage patterns.

@ymc9 ymc9 changed the title feat: implement field omission feat(orm): implement field omission Nov 27, 2025
@ymc9 ymc9 merged commit 2d740f1 into dev Nov 27, 2025
6 checks passed
@ymc9 ymc9 deleted the feat/omit branch November 27, 2025 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants