-
Notifications
You must be signed in to change notification settings - Fork 90
Move data loading concerns from join/order by to CollectionSubscription #564
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
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: 7077329 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 |
5ebdf33
to
9ebd6cf
Compare
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: +676 B (+0.99%) Total Size: 69.1 kB
ℹ️ View Unchanged
|
Size Change: 0 B Total Size: 1.44 kB ℹ️ View Unchanged
|
7d2dc56
to
f794615
Compare
* It uses that range index to load the items in the order of the index. | ||
* Note: it does not send keys that have already been sent before. | ||
*/ | ||
requestLimitedSnapshot({ limit, minValue }: RequestLimitedSnapshotOptions) { |
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.
Currently if there is an order by on a joined collection we only perform one of the optimisations? Is it only the join lookup or the orderBy?
This requestLimitedSnapshot
doesn't take a where
and so it can't support both a join and a orderBy index lookup at the same time.
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.
Exactly. If there is both a join and an orderBy (with a limit) we optimise only the orderBy because that's the first one we check in the code. The idea is that the limit is usually rather small and so it's better to load only a limited number of rows instead of all rows that match the join.
cafee6f
to
eb4e3eb
Compare
…sing the subscription's requestSnapshot method
… use it to lazily load data in queries with orderBy and limit
… returns a subscription object
15d1619
to
606cc85
Compare
Currently, our optimizations for the join and orderBy operators dynamically load data directly from the indexes. However, loading data should be a concern of the collection (subscription) instead of the query operators. Hence, we introduced a new
CollectionSubscription
class that represents a subscription that you get from callingcollection.subscribeChanges
. The subscription exposesrequestSnapshot
andrequestLimitedSnapshot
methods to dynamically load data. The subscription keeps track of data it has published and turnsupdates
intoinserts
(for keys that were not yet published) and filters out deletes of keys that weren't published yet.The
requestSnapshot
method loads a snapshot containing all values that fulfill the where clause you provide it (if you provide any). TherequestLimitedSnapshot
method will only load N items (configurable) that are bigger than a minimum value (optional). This method is used by the orderBy optimization to load only the amount of values it needs.