fix(orm): allow null for select/include/omit

[ymc9]

Summary by CodeRabbit

Release Notes

• Bug Fixes

  • ORM queries now accept null values for select, include, and omit parameters in find operations.

• Refactor

  • Updated validation logic to support explicit null values for database filtering parameters.

[coderabbitai]

Warning

Rate limit exceeded

@ymc9 has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 15 minutes and 39 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 0e582e0 and cabb7de.

📒 Files selected for processing (1)

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

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

The changes extend the SelectIncludeOmit type definition and corresponding validation schema to accept null values for the select, include, and omit properties. TypeScript type signatures are widened from optional to optional-or-null, and the validator schema is updated with .nullable() to enforce this at validation time.

Changes

Cohort / File(s)	Summary
Type and validation updates for nullable select/include/omit packages/orm/src/client/crud-types.ts, packages/orm/src/client/crud/validator/index.ts	SelectIncludeOmit type properties (select, include, omit) now accept | null in type signatures. Corresponding validator schema in makeFindSchema updated to use .nullable() on these three fields, allowing explicit null values during validation.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Changes follow a consistent, repetitive pattern applied uniformly across three properties
• Low logic density; modifications are primarily type and schema configuration updates
• Straightforward null-safety expansion with minimal structural impact
• Areas for attention:
  • Verify existing code paths handle null values correctly for select, include, and omit
  • Confirm no downstream logic assumes these properties are always defined when present
  • Check integration tests reflect null-value scenarios

Poem

🐰 With whiskers twitched and tail held high,
We welcome nulls beneath the sky!
Select, include, omit so free—
Now null's a valid possibility! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely summarizes the main change: allowing null values for select/include/omit properties in the ORM types and validator.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[claude]

Claude finished @ymc9's task —— View job

---

Code Review Complete

I'll review this PR that allows null for select/include/omit parameters. Let me analyze the changes:

Todo List

• Read and analyze the modified files
• Evaluate type safety implications
• Check for potential bugs or issues
• Assess performance and security considerations
• Review test coverage needs
• Provide comprehensive feedback

Review Summary

This PR makes a small but valuable improvement by allowing null values for select, include, and omit parameters in query operations.

Changes Analysis

Files Modified:

1. packages/orm/src/client/crud-types.ts:454-458 - Updated SelectIncludeOmit type to allow | null
2. packages/orm/src/client/crud/validator/index.ts:269-271 - Updated validators to accept .nullable() for these parameters

Code Quality Assessment

✅ Positive Aspects:

• Consistent Implementation: Both type definitions and runtime validators are updated together
• Clean & Minimal: The change is focused and doesn't introduce complexity
• Type Safety: Maintains type safety while adding flexibility
• API Ergonomics: Improves developer experience by accepting common JavaScript patterns

Technical Evaluation

Type Safety ✅

• The type changes properly extend the existing types to include null
• TypeScript will correctly handle null checks
• No breaking changes to existing code that doesn't use null

Runtime Validation ✅

• Zod validators properly updated with .nullable() calls
• Validation logic remains consistent between types and runtime
• No validation bypass or security issues

Performance ✅

• Zero performance impact
• No additional runtime overhead

Security ✅

• No security implications
• Null values are properly handled in the validation chain

API Design Considerations

This change aligns with common JavaScript/TypeScript patterns where:

• undefined typically means "not specified"
• null often means "explicitly set to nothing"

The change allows developers to write more natural code:

// Before: Had to omit or use undefined
const result = await db.user.findMany({ 
  select: someCondition ? { name: true } : undefined 
});

// After: Can use null more naturally  
const result = await db.user.findMany({ 
  select: someCondition ? { name: true } : null 
});

Test Coverage Assessment

• No new test files appear to be needed for this change
• The existing test suite should cover the new null behavior
• Runtime validation tests would ensure null values pass through correctly

Recommendations

1. ✅ Approve the change - This is a good improvement with minimal risk
2. 📝 Documentation: Consider updating API docs to mention null support
3. 🧪 Testing: Consider adding explicit tests for null values if not already covered

Summary

This is a well-implemented, low-risk change that improves API ergonomics without breaking existing functionality. The implementation correctly handles both TypeScript types and runtime validation. I recommend approving this PR.

[Copilot]

Pull Request Overview

This PR adds support for null values for the select, include, and omit fields in ORM queries. The changes ensure that these fields can accept null in addition to being optional or having their expected object/boolean values.

• Modified the Zod validator schemas to accept null values by chaining .nullable() after .optional()
• Updated TypeScript type definitions to include | null in the union types for these fields

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
packages/orm/src/client/crud/validator/index.ts	Added .nullable() to the Zod schema definitions for select, include, and omit fields in the makeFindSchema method
packages/orm/src/client/crud-types.ts	Updated TypeScript type definitions to include null in the union types for select, include, and omit in SelectIncludeOmit

---

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

[claude]

Claude finished @ymc9's task —— View job

---

Code Review Complete

I'll review this PR that allows null for select/include/omit parameters. Let me analyze the changes:

Todo List

• Read and analyze the modified files
• Evaluate type safety implications
• Check for potential bugs or issues
• Assess performance and security considerations
• Review test coverage needs
• Provide comprehensive feedback

Review Summary

This PR makes a small but valuable improvement by allowing null values for select, include, and omit parameters in query operations.

Changes Analysis

Files Modified:

1. packages/orm/src/client/crud-types.ts:454-458 - Updated SelectIncludeOmit type to allow | null
2. packages/orm/src/client/crud/validator/index.ts:269-271 - Updated validators to accept .nullable() for these parameters
3. packages/orm/src/client/crud/dialects/base-dialect.ts:866 - Updated function signature to accept null for omit parameter

Code Quality Assessment

✅ Positive Aspects:

• Consistent Implementation: Both type definitions and runtime validators are updated together
• Clean & Minimal: The change is focused and doesn't introduce complexity
• Type Safety: Maintains type safety while adding flexibility
• API Ergonomics: Improves developer experience by accepting common JavaScript patterns

Technical Evaluation

Type Safety ✅

• The type changes properly extend the existing types to include null
• TypeScript will correctly handle null checks
• No breaking changes to existing code that doesn't use null

Runtime Validation ⚠️ Critical Issue Found

The Copilot reviewer identified a significant bug in the mutual exclusivity refinements:

Problem: The refinements in refineForSelectIncludeMutuallyExclusive and refineForSelectOmitMutuallyExclusive use:

(value: any) => !(value['select'] && value['include'])

With the new nullable behavior, this logic is incorrect. For example:

• { select: null, include: {...} } should be valid (null means "not selecting")
• But null && {...} evaluates to null (falsy)
• So !(null && {...}) becomes true, incorrectly allowing the combination

Solution Needed: The refinement logic should explicitly check for non-null values:

// Current (broken with null)
(value: any) => !(value['select'] && value['include'])

// Should be (null-safe)
(value: any) => !(value['select'] != null && value['include'] != null)

This affects both refinement methods at lines 1501 and 1508.

Performance ✅

• Zero performance impact
• No additional runtime overhead

Security ✅

• No security implications
• Null values are properly handled in the validation chain

API Design Considerations

This change aligns with common JavaScript/TypeScript patterns where:

• undefined typically means "not specified"
• null often means "explicitly set to nothing"

The change allows developers to write more natural code:

// Before: Had to omit or use undefined
const result = await db.user.findMany({ 
  select: someCondition ? { name: true } : undefined 
});

// After: Can use null more naturally  
const result = await db.user.findMany({ 
  select: someCondition ? { name: true } : null 
});

Test Coverage Assessment

• The existing test suite should cover most scenarios
• Recommend adding tests for null values in combination scenarios
• Specifically test cases like { select: null, include: {...} } to ensure they work correctly

Recommendations

1. 🛑 Fix Critical Bug: Update the mutual exclusivity refinements to handle null correctly
2. 🧪 Add Tests: Add explicit tests for null value combinations
3. 📝 Documentation: Consider updating API docs to mention null support
4. ✅ Approve After Fix: The concept is good, but the refinement bug must be addressed

Summary

This is a well-intentioned improvement that enhances API ergonomics, but it contains a critical bug in the validation logic that must be fixed before merging. The mutual exclusivity checks don't properly handle the new null values, potentially allowing invalid combinations.

---