Move data loading concerns from join/order by to CollectionSubscription#564
Move data loading concerns from join/order by to CollectionSubscription#564
Conversation
🦋 Changeset detectedLatest commit: fa9d49a The changes in this PR will be included in the next version bump. This PR includes changesets to release 13 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: +742 B (+1.08%) 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.
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.
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
Co-authored-by: Sam Willis <sam.willis@gmail.com>
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
CollectionSubscriptionclass that represents a subscription that you get from callingcollection.subscribeChanges. The subscription exposesrequestSnapshotandrequestLimitedSnapshotmethods to dynamically load data. The subscription keeps track of data it has published and turnsupdatesintoinserts(for keys that were not yet published) and filters out deletes of keys that weren't published yet.The
requestSnapshotmethod loads a snapshot containing all values that fulfill the where clause you provide it (if you provide any). TherequestLimitedSnapshotmethod 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.