Feature/rest upsert #1863
Feature/rest upsert #1863
Conversation
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... 📒 Files selected for processing (2)
📝 Walkthrough📝 WalkthroughWalkthroughThe changes introduce a new Changes
Possibly related PRs
Suggested reviewers
Tip CodeRabbit can generate a title for your PR based on the changes.Add @coderabbitai placeholder anywhere in the title of your PR and CodeRabbit will replace it with a title based on the changes in the PR. You can change the placeholder by changing the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
I refactored this to treat upserts as peers to creates etc. I'm much happier with this version. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
packages/server/src/api/rest/index.ts (1)
312-333: Consider typing the request body for better type safetyCurrently, the request body is cast to
any. Defining a specific type for the request body can enhance type safety and catch potential errors at compile time.Apply this diff to improve type safety:
- const body = requestBody as any; + interface RequestMeta { + operation?: string; + matchFields?: string[]; + } + + interface RequestBody { + meta?: RequestMeta; + } + + const body = requestBody as RequestBody;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
packages/server/src/api/rest/index.ts(3 hunks)packages/server/tests/api/rest.test.ts(2 hunks)
🧰 Additional context used
🪛 eslint
packages/server/tests/api/rest.test.ts
[error] 9-9: 'query' is defined but never used. Allowed unused vars must match /^_/u.
(@typescript-eslint/no-unused-vars)
🔇 Additional comments (6)
packages/server/src/api/rest/index.ts (2)
860-865: Review the exclusion of match fields from the update data
In the upsert operation, match fields are excluded from the update data. There might be cases where match fields need to be updated. Consider allowing match fields to be updated if it aligns with the business logic.
1402-1419: Verify the construction of the 'where' clause for compound IDs
Ensure that the makeUpsertWhere method correctly constructs the where clause for models with compound IDs. Incorrect construction may lead to unexpected behavior during upsert operations.
Run the following script to verify the correctness:
✅ Verification successful
Based on the comprehensive analysis of the codebase, I can now provide a final response:
The compound ID handling in makeUpsertWhere is correctly implemented
The implementation correctly handles both single and compound IDs by:
- Creating a base
whereobject from all match fields - For compound IDs (when
typeInfo.idFields.length > 1), it properly wraps the fields using Prisma's compound ID format withprismaIdDivider('_') - The implementation is validated by test cases in
packages/server/tests/api/rest.test.tswhich include models with compound IDs likePostLikeandUser
The code is consistent with Prisma's compound ID requirements and is properly tested with various scenarios including:
- Models with
@@id([field1, field2]) - Proper handling of the
prismaIdDividerconstant - Integration with Prisma's query format
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find usages of 'makePrismaIdKey' and ensure correct 'where' clause construction.
# Search for 'makePrismaIdKey' usages in the codebase
rg 'makePrismaIdKey' -A 5 -B 5
# Search for models with compound IDs
grep -r '@@id' ./prisma/schema.prisma
# Verify upsert operations on models with compound IDs
# (Assuming test cases are available)
cd tests && npm run test-upsert-compound-id
Length of output: 5694
Script:
#!/bin/bash
# Let's analyze the implementation and usage of makeUpsertWhere more thoroughly
# First, let's find the definition of prismaIdDivider constant
rg "prismaIdDivider" -B 2 -A 2
# Find all model definitions to check for compound IDs
fd "schema.prisma" --type f
# Look for test files related to upsert operations
fd "upsert" --type f
# Look for actual usage of makeUpsertWhere
rg "makeUpsertWhere" -B 5 -A 5
# Look for model info type definition
rg "type ModelInfo" -A 10
Length of output: 5704
Script:
#!/bin/bash
# Let's examine the implementation of compound IDs in the test projects' schema files
# Check the schema files for compound ID definitions
cat packages/plugins/trpc/tests/projects/nuxt-trpc-v10/prisma/schema.prisma
cat packages/plugins/trpc/tests/projects/nuxt-trpc-v11/prisma/schema.prisma
cat packages/plugins/trpc/tests/projects/t3-trpc-v10/prisma/schema.prisma
cat packages/plugins/trpc/tests/projects/t3-trpc-v11/prisma/schema.prisma
# Look for test files that might be using compound IDs
rg "@@id" --type ts -B 5 -A 5
# Look for the FieldInfo type definition to understand ID field structure
rg "type FieldInfo" -A 10
Length of output: 63505
packages/server/tests/api/rest.test.ts (4)
1805-1841: Test case for upserting a new entity is correctly implemented
The test case effectively verifies the upsert operation when creating a new entity. It asserts that the entity is created and the response matches the expected structure.
1843-1874: Test case for upserting an existing entity works as expected
This test correctly checks that the upsert operation updates an existing entity when the match field matches, ensuring that the existing entity is updated with new attributes.
1876-1912: Test case accurately captures upsert failure due to non-unique matchFields
The test verifies that an upsert operation fails with a proper error when the specified matchFields are not unique, ensuring the system correctly handles such cases.
1914-1937: Test case confirms upsert operation with compound IDs functions correctly
This test ensures that the upsert operation supports entities with compound IDs using multiple matchFields, confirming that the feature works as intended.
There was a problem hiding this comment.
Hi @thomassnielsen , overall it looks very good to me. Please check the few comments I left. Thanks!
| ), | ||
| }; | ||
| upsertPayload.update[key] = { | ||
| connect: enumerate(data.data).map((item: any) => |
There was a problem hiding this comment.
I'm wondering if the semantic for the "update" case should use "set" instead of "connect" here - replace the entire connection collection instead of adding new ones?
| return error; | ||
| } | ||
|
|
||
| const matchFields = (requestBody as any).meta.matchFields; |
There was a problem hiding this comment.
matchFields should always be string[], right? Shall we zod validate it?
There was a problem hiding this comment.
Yes an optional array of strings. It makes sense to zod validate it. Where would this be added?
There was a problem hiding this comment.
I see you currently have a check body?.meta?.operation === 'upsert'. Maybe we can define a zod schema and replace that check with zod parse?
Adds support for upsert operations in the RESTAPIHandler via metadata.
We may also want to add documentation about this to the OpenAPI generator.
Discussion in Discord