-
Notifications
You must be signed in to change notification settings - Fork 99
asc/desc index bug #623
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
asc/desc index bug #623
Conversation
🦋 Changeset detectedLatest commit: 5a26e2d 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/query-db-collection
@tanstack/react-db
@tanstack/rxdb-db-collection
@tanstack/solid-db
@tanstack/svelte-db
@tanstack/trailbase-db-collection
@tanstack/vue-db
commit: |
Size Change: +346 B (+0.47%) Total Size: 74.5 kB
ℹ️ View Unchanged
|
Size Change: 0 B Total Size: 1.44 kB ℹ️ View Unchanged
|
The bug occurs because we store an index for a given column but we don't track the comparison options (direction, nulls, stringSort) that were used to construct the index. Hence, when we do a first query we may create an index on a given column (say in ascending order) and then later another query may order by the same column but in descending order but it will re-use the same index because the index lookup function only checks the column name and not the comparison options. I solved this bug by adding the comparison options to the index' state and making sure that I added some additional unit tests and modified the unit tests for stringSort and nulls such that they also break (because the wrong index is used). With the fix, these tests now pass. However, the tests showed that there is another bug when the indexed column contains null values and the query uses orderBy + limit + eager indexing mode. Under those circumstances the returned results become empty. With the current fix, we would create 2 indexes: one for ASC order and one for DESC order. That is suboptimal. As a follow up we should re-use the existing index and walk it in reverse order. We can write a |
This is all good and ready to merge. I can't approve as I originally opened the PR with the tests... "I approve" |
repo of #616