fix(docs): correct spread order in defineRelationsPart example#679
Open
morgan-coded wants to merge 1 commit into
Open
fix(docs): correct spread order in defineRelationsPart example#679morgan-coded wants to merge 1 commit into
morgan-coded wants to merge 1 commit into
Conversation
The "Why it's important?" callout in the Relations Parts section showed the
same spread order `{ ...relations, ...part }` for both the kept and the lost
result objects, making the two outcomes indistinguishable.
The second example illustrates the case where the main relations object is
spread last, so its empty `posts: {}` placeholder overwrites the relation
defined in `part` ("posts relations information will be lost"). That outcome
corresponds to `{ ...part, ...relations }`, so the second snippet is updated to
use that order.
Closes drizzle-team#629
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Documentation fix correcting the spread order shown in an example explaining how relations and partial selections merge.
Changes:
- Corrected the object spread order in an explanatory sentence from
{ ...relations, ...part }to{ ...part, ...relations }to match the resulting JSON shown below it.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The "Why it's important?" callout in the Relations Parts section of the Drizzle Relations (v2) docs shows the same spread order
{ ...relations, ...part }for both result objects — the one that keeps the relation and the one where "posts relations information will be lost". With identical spread orders the two outcomes are indistinguishable, which is the bug reported in #629.defineRelationsseeds an empty placeholder (posts: {}) for every table, and object spread is last-key-wins:{ ...relations, ...part }.posts→{ author: {...} }(relation kept){ ...part, ...relations }.posts→{}(relation lost)The second example is the "lost" case, so its spread order is corrected to
{ ...part, ...relations }.Closes #629