Rust SDK: Actual client-side indices for unique constraints #1909
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This turns out to be effectively a prerequisite for client-side indices. Storing indexes in a type-erased way while making them `Clone` for storage in `im::HashMap` is likely possible, but it's at least very challenging and complex. Given that we no longer actually need the concurrent persistence offered by `im::HashMap`, it seems easier to just revert to using `std::collections::HashMap`.
As opposed to having a bunch of `#[doc(hidden)] pub mod`s with a variety of different purposes. This means we can reorganize the SDK internals without breaking codegen.
Updates unique constraint `.find` methods on clients to be backed by actual indices, rather than O(n) full scans. Specifically, unique indices on clients are `HashMap`s, whereas on the server they are `BTreeMap`s. This is because: - It was easier given that I haven't implemented client-side non-unique indices yet. - We artifically restrict filter methods to a small set of known types, all of which are both `Ord` and `Hash`, so there's not much difference. - `HashMap` is marginally more efficient, I guess? Associated changes: - Codegen now includes a mechanism for registering each table in the `ClientCache` during `DbConnectionBuilder::build`, where previously they were lazily added the first time a row was inserted into them. This is necessary so that the codegen can install unique indices up front. - The codegen actually discriminates on filterable types now, and does not emit indices or access methods for unique columns of non-filterable types.
And make `CallReducerFlags` be unstable, and export it from the unstable mod.
coolreader18
approved these changes
Nov 27, 2024
|
Merging this and closing its two parents, rather than going through the rigamarole of merging each individually and rebasing. |
This was referenced Nov 29, 2024
cloutiertyler
pushed a commit
that referenced
this pull request
Dec 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of Changes
Based on #1900 , which in turn is based on #1897 .
Updates unique constraint
.findmethods on clients to be backed by actual indices, rather than O(n) full scans. Specifically, unique indices on clients areHashMaps, whereas on the server they areBTreeMaps. This is because:OrdandHash, so there's not much difference.HashMapis marginally more efficient, I guess?Associated changes:
ClientCacheduringDbConnectionBuilder::build, where previously they were lazily added the first time a row was inserted into them. This is necessary so that the codegen can install unique indices up front.API and ABI breaking changes
Rust SDK codegen changes and will require re-running
spacetime generate. Unique filter methods on columns of non-filterable types which were erroneously generated prior to now are no longer generated, so clients which depend on them will break.Expected complexity level and risk
2 - codegen's always fiddly, but slapping a few extra
HashMaps around is pretty simple.Testing
.findmethods behaving correctly.