-
Notifications
You must be signed in to change notification settings - Fork 11
Fix large table issues #179
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
…. Also add a slightly more optimal code path for initial subscriptions.
|
Thank you for opening this! We'll try to take a look soon. |
commit: |
Description of Changes
Changes were made to handle large data table changes. Changes and why they were made are outlined in this discord chat.
https://discord.com/channels/1037340874172014652/1363015282381033613/1363972150922444935
Main changes are modifying the applyTableUpdates and applyOperations to handle larger row counts. Currently a million rows will completely fail in the sdk. This is due to a bug causing a stack overflow & the OperationMap having very poor performance characteristics.
I fixed this by not allocating all the pendingCallbacks on the stack and changing the applyOperations to use a normal Map rather than the OperationMap which uses an internal list for its data structure.
To make complex keys compatible with a normal map I introduced the
toPrimaryKey
on complex key types like connectionId and Identity. This converts them to a hashable format and allows them to pas all existing tests.API
This changes no interface so should not be a breaking change. It has been tested with all key types as far as I can tell so do not believe it should break any underlying functionality.
Requires SpacetimeDB PRs
This is the only PR required.
Testing
I compiled this code and tested it in my app for testing and it worked great.
https://github.com/ChaseLewis/place-rs
I also ran all existing automated testing which it passed locally on my machine.