-
Notifications
You must be signed in to change notification settings - Fork 120
Fix: do not dedupe loadSubset calls in query collection
#835
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
|
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: |
|
Size Change: 0 B Total Size: 86 kB ℹ️ View Unchanged
|
|
Size Change: 0 B Total Size: 3.34 kB ℹ️ View Unchanged
|
KyleAMathews
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.
Thanks for investigating! Let's get this merged/shipped to unbreak people.
Fixes #827 by temporarily disabling deduplication in the query collection. We do want to re-introduce it properly in the near future as described in #836.
The deduplication logic of
loadSubsetcalls in the query collection is currently causing problems because upon deduplicating aloadSubsetcall we do not track which other queries are the reason why we can deduplicate this one. As a result, when the original query (or queries) is/are GCed this deduplicated query doesn't know that and continues to load stale data from the local collection (and the local collection won't receive updates to these rows anymore).Keeping track of which queries are deduplicated because of which other queries would be quite complex. So instead, we remove this optimization for now and will rely on the query keys to deduplicate queries.