-
Notifications
You must be signed in to change notification settings - Fork 167
fix: normalize keys before join operation #1229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 Changeset detectedLatest commit: 5bcb579 The changes in this PR will be included in the next version bump. This PR includes changesets to release 12 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
More templates
@tanstack/angular-db
@tanstack/db
@tanstack/db-ivm
@tanstack/electric-db-collection
@tanstack/offline-transactions
@tanstack/powersync-db-collection
@tanstack/query-db-collection
@tanstack/react-db
@tanstack/rxdb-db-collection
@tanstack/solid-db
@tanstack/svelte-db
@tanstack/trailbase-db-collection
@tanstack/vue-db
commit: |
…tion The join lazy-loading path passes normalized join keys (e.g. Date→timestamp) into `inArray`, but the `in` evaluator compared raw field values against them using `Array.includes` (strict equality). This meant the optimization silently fell back to loading the full collection for Date-keyed joins. Normalize the value in the `in` evaluator, consistent with how `eq` already normalizes both operands. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Thanks for the fix! I pushed an additional commit to also normalize the value in the Why this is needed: The join compiler has a lazy-loading optimization where the active side's join keys are passed into The fix normalizes the value in the |
Move the two Date join tests from the separate join-date.test.ts file into the existing Complex Join Scenarios block in join.test.ts, keeping all join tests in one place. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Adds a test verifying that inArray correctly filters rows by Date field values when the array contains Date objects. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The `in` evaluator used `array.includes(value)` which relies on strict equality. When either the value or the array elements are Date objects (or other types that normalizeValue handles), reference equality fails even when the underlying values are the same. Normalize array elements via `array.some(item => normalizeValue(item) === value)` so that both sides are compared as primitives, consistent with how `eq` already normalizes both operands. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
While reviewing, I found an additional related bug: For example, This is the same class of bug as the original join issue — just in a different code path. The fix (commit 3a23b30) normalizes both the value and the array elements in the // Before
return array.includes(value)
// After
return array.some((item) => normalizeValue(item) === value)This makes |
samwillis
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
![]()
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
🎉 This PR has been released! Thank you for your contribution! |
Description
To fix the issue #934
Problem
eq(left.date, right.date)were using raw Date object as join keysSolution