feat(orm): implement json filters #472
Conversation
|
Claude finished @ymc9's task —— View job JSON Filters Implementation ReviewI've completed my analysis of the JSON filters implementation in this pull request. Here's my comprehensive review: Review Checklist:
SummaryThis PR implements comprehensive JSON filtering capabilities for both PostgreSQL and SQLite dialects. The implementation includes path-based queries, string operations, array filtering, and proper null handling across different database systems. Positive Aspects1. Comprehensive Type Safety ✅The implementation properly extends the existing type system:
2. Database-Specific Implementations ✅Both dialects handle JSON filtering appropriately:
3. Robust Null Handling ✅The implementation correctly distinguishes between:
4. Extensive Test Coverage ✅The test suite covers:
Potential Issues & Recommendations1. Security Concerns
|
|
Note Other AI code review bot(s) detectedCodeRabbit 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. WalkthroughExtended JSON filtering: added path, string-pattern, case-insensitive mode, and array predicates to types and validator; refactored filter building in BaseCrudDialect and added abstract JSON path/array hooks implemented for Postgres and SQLite; updated tests and model name; small test-client debug log added. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Pull request overview
This PR implements comprehensive JSON filtering capabilities for the ORM, adding support for path-based selection and various filter operations on JSON fields including string and array filters.
Key Changes
- Added JSON path selection with support for nested object and array access via
pathfield - Implemented string filters (
string_contains,string_starts_with,string_ends_with) with optional case sensitivity control - Implemented array filters (
array_contains,array_starts_with,array_ends_with) for JSON arrays - Renamed test model from
PlainJsontoFoofor consistency with naming conventions
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| tests/e2e/orm/schemas/json/schema.zmodel | Renamed model from PlainJson to Foo |
| tests/e2e/orm/schemas/json/schema.ts | Updated model name in generated schema |
| tests/e2e/orm/schemas/json/models.ts | Updated model type export |
| tests/e2e/orm/schemas/json/input.ts | Updated all type definitions for renamed model |
| tests/e2e/orm/client-api/json-filter.test.ts | Updated tests with renamed model and added comprehensive tests for new JSON filter features (path selection, string filters, array filters) |
| packages/testtools/src/client.ts | Added database name to debug logging output |
| packages/orm/src/client/crud/validator/index.ts | Added validation schema for new JSON filter fields including path, string filters, array filters, and mode |
| packages/orm/src/client/crud/dialects/sqlite.ts | Implemented SQLite-specific JSON path selection using json_extract and array filters using json_each |
| packages/orm/src/client/crud/dialects/postgresql.ts | Implemented PostgreSQL-specific JSON path selection using jsonb_extract_path functions and array filters using JSONB operators |
| packages/orm/src/client/crud/dialects/base-dialect.ts | Added core logic for processing JSON filters with path selection, string filters, and array filters |
| packages/orm/src/client/crud-types.ts | Added TypeScript type definitions for new JSON filter operations |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
packages/orm/src/client/crud/validator/index.ts (1)
611-621: JsonFilter Zod schema matches new operators; consider aligning array_ null semantics with types*The stricter
z.strictObjectwithpath,string_*, andarray_*fields cleanly aligns runtime validation with the extended JsonFilter shape and correctly reusesvalueSchemasoDbNull/JsonNull/AnyNullare allowed where the underlying JSON field is optional.One inconsistency:
array_contains,array_starts_with, andarray_ends_withhere accept the fullvalueSchema(including null sentinel classes for optional JSON fields), while theJsonFiltertype declares these asJsonValueonly. You might want to either:
- Narrow the Zod schema for
array_*to exclude the null sentinels, or- Widen the TS type of
array_*toJsonValue | JsonNullValuesfor parity withequals/not.This will keep compile‑time types and runtime validation behavior in sync for array filters.
packages/orm/src/client/crud-types.ts (1)
460-471: JsonFilter type matches new capabilities; revisit array_ element typing*The extended
JsonFiltertype (path, string_, array_ and mode) lines up with the new validation and dialect behavior and keeps existing equals/not semantics.Given the validator currently allows
DbNull/JsonNull/AnyNullforarray_*when the field is optional, you may want to decide explicitly whether array filters should support those sentinels:
- If yes, consider changing the signatures to
array_*?: JsonValue | JsonNullValues;, or- If no, update the Zod schema to only accept plain
JsonValuefor array_* and perhaps add tests asserting that passing null sentinel values is rejected.Clarifying this will avoid surprises for TS users relying on these types.
packages/orm/src/client/crud/dialects/sqlite.ts (1)
362-401: SQLite JSON path/array implementations look correct; document or constrain edge casesThe new SQLite implementations for JSON path selection and array filters are consistent with JSON1:
buildJsonPathSelectioncorrectly uses$.foo[0].barstyle paths and returns the receiver unchanged for an empty path (needed for top‑level string filters).buildJsonArrayFiltermaps the newarray_*operators tojson_each,json_extract('$[0]'), andjson_extract('$[last]'), which aligns with the e2e tests for scalar array elements.A few edge considerations you may want to address:
- Complex path segments: Property names with dots, brackets, or quotes aren’t escaped (they’re emitted as
.${segment}), so such keys can’t be targeted. If that’s acceptable, consider documenting thatpathsegments are expected to be simple identifiers or numeric indices; otherwise, switch to["segment"]style for general keys.- Non‑scalar array elements:
array_containscomparesjson_each(value)directly to the bound value. That’s fine for strings/numbers/booleans, but semantics for objects/arrays may be surprising unless the driver/json_each agree on serialization. Either constrainarray_*to scalar values in types/validator or add tests for arrays of objects to pin down expected behavior.- _asType parameter:
_asTypeis currently unused here; if the base class relies on it to distinguish string vs JSON behavior in other dialects, it may be worth adding a brief comment noting that SQLite’sjson_extractalready returns appropriately typed values.Overall the implementation looks sound; these notes are mainly about clarifying and tightening behavior around less common cases.
tests/e2e/orm/client-api/json-filter.test.ts (1)
499-656: Array filter path tests are comprehensive; consider adding arrays‑of‑objects caseThe path‑based array filter tests extensively cover:
array_contains,array_starts_with, andarray_ends_withon scalar arrays (tags,numbers) and nested arrays (nested.items).- Positive and negative cases, plus non‑existent paths.
Given the implementation in the dialect, these tests are excellent for scalar array elements. One potential enhancement would be to add a case where the array holds JSON objects (e.g.
{ kind: 'tag', value: 'react' }) and you filter witharray_containson such an object; that would both document and lock in the intended semantics for complex JSON elements in arrays.packages/orm/src/client/crud/dialects/base-dialect.ts (2)
528-575: JSON path, string, and array filter wiring looks coherent; consider behavior of unsupported keysThe refactored
buildJsonFiltercleanly:
- Normalizes
pathonce and usesbuildJsonPathSelectionto derive JSON and string receivers.- Validates
modeand routes string predicates throughbuildJsonStringFilter.- Delegates array predicates to
buildJsonArrayFilter, keeping dialect specifics out of the base class.
buildJsonStringFilter’s use ofsupportsILikefromgetStringCasingBehavioris a good abstraction for dialects like PostgreSQL vs SQLite.One behavioral note: any keys other than the explicit cases (
equals,not,string_*,array_*, as well aspath/mode) are currently ignored rather than rejected. If the Zod validator ever loosens, you may want to add anotherwisebranch that throwscreateInvalidInputErrorfor unexpected JSON filter keys, mirroring how other filter builders enforce valid operators.Also applies to: 590-607
1301-1319: New JSON path/array abstract methods are well‑placed extension pointsThe new protected abstracts:
buildJsonPathSelection(receiver, path, asType)buildJsonArrayFilter(lhs, operation, value)fit naturally alongside the other dialect hooks and keep JSON‑specific SQL out of the base implementation. This should make it straightforward for each dialect to implement its own JSON path semantics without touching shared filter logic. No issues from a type/contract standpoint (once concrete implementations match
path: string[]andExpression<SqlBool>).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
packages/orm/src/client/crud-types.ts(1 hunks)packages/orm/src/client/crud/dialects/base-dialect.ts(3 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/validator/index.ts(1 hunks)packages/testtools/src/client.ts(1 hunks)tests/e2e/orm/client-api/json-filter.test.ts(6 hunks)tests/e2e/orm/schemas/json/input.ts(1 hunks)tests/e2e/orm/schemas/json/models.ts(1 hunks)tests/e2e/orm/schemas/json/schema.ts(1 hunks)tests/e2e/orm/schemas/json/schema.zmodel(1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.zmodel
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.zmodel: Always runzenstack generateafter modifying ZModel schemas
ZModel schema files should define database structure and policies that compile to TypeScript viazenstack generate
Files:
tests/e2e/orm/schemas/json/schema.zmodel
tests/e2e/**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
E2E tests should validate real-world schema compatibility with established projects
Files:
tests/e2e/orm/schemas/json/schema.tstests/e2e/orm/client-api/json-filter.test.tstests/e2e/orm/schemas/json/models.tstests/e2e/orm/schemas/json/input.ts
🧠 Learnings (8)
📓 Common learnings
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
Learning: Applies to tests/e2e/**/*.{ts,tsx} : E2E tests should validate real-world schema compatibility with established projects
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
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
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
Learning: Applies to packages/zenstackhq/orm/**/*.{ts,tsx} : Implement plugin hooks at ORM, Kysely, and entity mutation levels for query interception and customization
📚 Learning: 2025-11-26T01:55:04.540Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
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/json/schema.zmodeltests/e2e/orm/schemas/json/schema.tstests/e2e/orm/schemas/json/models.ts
📚 Learning: 2025-11-26T01:55:04.540Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
Learning: Applies to tests/e2e/**/*.{ts,tsx} : E2E tests should validate real-world schema compatibility with established projects
Applied to files:
tests/e2e/orm/schemas/json/schema.zmodelpackages/orm/src/client/crud/validator/index.tstests/e2e/orm/schemas/json/schema.tstests/e2e/orm/client-api/json-filter.test.tstests/e2e/orm/schemas/json/models.ts
📚 Learning: 2025-11-26T01:55:04.540Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
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/crud/validator/index.tstests/e2e/orm/client-api/json-filter.test.ts
📚 Learning: 2025-11-26T01:55:04.540Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
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/crud/validator/index.tspackages/orm/src/client/crud/dialects/sqlite.tspackages/orm/src/client/crud/dialects/postgresql.tspackages/orm/src/client/crud/dialects/base-dialect.tstests/e2e/orm/client-api/json-filter.test.ts
📚 Learning: 2025-11-26T01:55:04.540Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
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/validator/index.tspackages/orm/src/client/crud/dialects/postgresql.tspackages/orm/src/client/crud/dialects/base-dialect.tstests/e2e/orm/schemas/json/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/postgresql.tspackages/orm/src/client/crud/dialects/base-dialect.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/json/schema.ts
🧬 Code graph analysis (4)
packages/orm/src/client/crud-types.ts (1)
packages/orm/src/utils/type-utils.ts (2)
JsonValue(48-48)JsonNullValues(53-53)
packages/orm/src/client/crud/dialects/postgresql.ts (1)
packages/orm/src/helpers.ts (1)
sql(1-1)
packages/orm/src/client/crud/dialects/base-dialect.ts (1)
packages/common-helpers/src/tiny-invariant.ts (1)
invariant(4-14)
tests/e2e/orm/client-api/json-filter.test.ts (1)
packages/orm/src/client/index.ts (2)
JsonNull(7-7)DbNull(7-7)
⏰ 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). (5)
- GitHub Check: Agent
- GitHub Check: CodeQL analysis (javascript-typescript)
- GitHub Check: build-test (20.x, postgresql)
- GitHub Check: build-test (20.x, sqlite)
- GitHub Check: claude-review
🔇 Additional comments (9)
packages/testtools/src/client.ts (1)
158-162: Additional debug log for database name is fineLogging the database name alongside the work directory in debug mode is low-risk and should help when diagnosing per‑test databases; no functional issues spotted.
tests/e2e/orm/schemas/json/schema.ts (1)
14-38: Generated schema rename toFoolooks consistentThe model key and
namefield are consistently renamed toFoowhile preserving the field layout. Just ensure this file is produced viazenstack generatefrom the updatedschema.zmodel, not hand-edited, to honor the “DO NOT MODIFY” notice. As per coding guidelines, ZModel changes should be regenerated into TS artifacts.tests/e2e/orm/schemas/json/schema.zmodel (1)
5-9: Model renamed toFoo; remember to regenerate schema artifactsThe
Foomodel definition looks fine and keeps the original field structure. After modifying this.zmodel, make surezenstack generatehas been run so thatschema.ts,models.ts, and related artifacts stay in sync. As per coding guidelines, ZModel schemas should be the single source of truth.tests/e2e/orm/schemas/json/models.ts (1)
8-10: GeneratedFoomodel alias matches schemaThe exported
Footype correctly targets the"Foo"model in the generated schema. As withschema.ts, ensure this file is generated (not manually edited) from the updated.zmodelviazenstack generateso types remain in sync. As per coding guidelines, ...tests/e2e/orm/client-api/json-filter.test.ts (4)
1-212: Existing JSON null semantics tests remain solid afterfoomodel renameThe switch from the previous model name to
db.foothroughout the null‑semantics, update, and “JSON with nulls” tests keeps the original behavior intact:
- JsonNull vs DbNull vs AnyNull are still exercised on both
dataanddata1.- Invalid inputs (
null/DbNullin the wrong places) are guarded via validation expectations.- Typed JSON filtering via
typedJsonSchemacontinues to work as before.This maintains strong regression coverage around JSON null handling while aligning with the new model naming.
231-314: Path‑based equality tests cover nested objects and array indices wellThe
path selection equalitytest thoroughly checks:
- Empty path vs entire document.
- Nested paths through objects (
['a'],['a', 'b']).- Array indexing via string indices (
['x', '1']vs['x', '0']).- Mismatched paths returning
null.This nicely validates the new
path+equalsbehavior across common shapes and index addressing.
316-458: Path string filter tests give good cross‑provider coverageThe string filter tests do a good job of:
- Exercising
string_contains,string_starts_with, andstring_ends_withon paths into objects and arrays.- Verifying case‑insensitive behavior via
mode: 'insensitive'.- Using
getTestDbProviderto assert PostgreSQL‑only case‑sensitivity semantics while skipping those expectations for SQLite.- Including non‑existent path and non‑matching substring cases.
This suite should catch most provider‑specific regressions in JSON string filtering along paths and looks well aligned with real‑world usage patterns. Based on learnings, this is strong e2e coverage for ORM client APIs.
460-497: Top‑level string filter tests nicely confirmpathdefaultsThe top‑level tests validate that:
data: { string_contains: 'World' }works without apath.path: []behaves equivalently.- Non‑matching substrings correctly yield no result.
That’s a useful sanity check that the empty
pathconvention matches the default behavior on the root JSON value.tests/e2e/orm/schemas/json/input.ts (1)
11-30: Generated Foo input types correctly reflect the model rename*The Foo* argument/select/include/omit/get‑payload aliases cleanly swap
"PlainJson"for"Foo"while preserving the generic shapes. This keeps the E2E JSON tests aligned with the updated schema and ORM surface without changing behavior.
Co-authored-by: Copilot <[email protected]>
|
Claude finished @ymc9's task —— View job Claude finished reviewing the JSON filters implementation JSON Filters Implementation ReviewI've completed my analysis of the JSON filters implementation in this pull request. Here's my comprehensive review: Review Checklist:
SummaryThis PR implements comprehensive JSON filtering capabilities for both PostgreSQL and SQLite dialects. The implementation includes path-based queries, string operations, array filtering, and proper null handling across different database systems. Positive Aspects1. Comprehensive Type Safety ✅The implementation properly extends the existing type system:
2. Database-Specific Implementations ✅Both dialects handle JSON filtering appropriately:
3. Robust Null Handling ✅The implementation correctly distinguishes between:
4. Extensive Test Coverage ✅The test suite covers:
Potential Issues & Recommendations1. Security Concerns
|
|
Claude finished @ymc9's task —— View job JSON Filters Implementation ReviewI've completed my analysis of the JSON filters implementation in this pull request. Here's my comprehensive review: Review Checklist:
SummaryThis PR implements comprehensive JSON filtering capabilities for both PostgreSQL and SQLite dialects. The implementation includes path-based queries, string operations, array filtering, and proper null handling across different database systems. Positive Aspects1. Comprehensive Type Safety ✅The implementation properly extends the existing type system:
2. Database-Specific Implementations ✅Both dialects handle JSON filtering appropriately:
3. Robust Null Handling ✅The implementation correctly distinguishes between:
4. Extensive Test Coverage ✅The test suite covers:
Potential Issues & Recommendations1. Security Concerns
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
packages/orm/src/client/crud/dialects/base-dialect.ts (2)
524-581: JSON filter path/mode handling and key validation look solid; minor error-type consistency nitPrecomputing
path/receivers, validatingmode, and explicitly skippingpath/modein the switch all look correct, and the new string/array cases integrate cleanly withbuildJsonValueFilterClause/buildJsonArrayFilter. One small consistency nit: thedefaultbranch usesinvariant(false, ...)while other filter builders usecreateInvalidInputError(...)for invalid keys; if you want uniform user-facing errors, consider switching tocreateInvalidInputErrorhere or add a brief comment that this branch is effectively unreachable due to the validator.
596-612: JSON string filter helper is well-implemented; consider sharing it with scalar string filtersThe LIKE/ILIKE pattern construction and
supportsILikecheck give you dialect-aware case-insensitive matching for JSON string paths and align with existing string filter semantics. To reduce duplication and keep behavior consistent, you might factor this into a shared helper (or call it) frombuildStringFilterso both JSON and scalar string filters use the same casing behavior and operator selection.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
TODO.md(1 hunks)packages/orm/src/client/crud/dialects/base-dialect.ts(3 hunks)packages/orm/src/client/crud/dialects/postgresql.ts(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/orm/src/client/crud/dialects/postgresql.ts
🧰 Additional context used
🧠 Learnings (3)
📚 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
📚 Learning: 2025-11-26T01:55:04.540Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
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/crud/dialects/base-dialect.ts
📚 Learning: 2025-11-26T01:55:04.540Z
Learnt from: CR
Repo: zenstackhq/zenstack-v3 PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-26T01:55:04.540Z
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
🪛 markdownlint-cli2 (0.18.1)
TODO.md
89-89: Unordered list indentation
Expected: 4; Actual: 8
(MD007, ul-indent)
⏰ 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 (1)
packages/orm/src/client/crud/dialects/base-dialect.ts (1)
1307-1324: New JSON path/array abstract hooks look appropriate and align with the filter logicThe signatures for
buildJsonPathSelection(withasType: 'string' | 'json') andbuildJsonArrayFiltergive dialects enough flexibility to implement Postgres/SQLite-specific behavior while keepingBaseCrudDialectgeneric. As long as concrete dialects treat an emptypathas identity and honor the DbNull/JsonNull semantics expected bybuildJsonValueFilterClause, this abstraction layer looks good.
Summary by CodeRabbit
New Features
Tests
Chores
✏️ Tip: You can customize this high-level summary in your review settings.