-
Notifications
You must be signed in to change notification settings - Fork 109
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
Eliminate dependency on im
; just mutate the client cache
#1897
Conversation
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`.
455f5be
to
3e2c168
Compare
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.
LGTM, but I think needs more eyes.
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.
Looks good, but I'd ask that this go after 2 websocket/sdk PRs I have.
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.
This all makes sense to me, but I'm not that familiar with the rust sdk so I'm not confident approving.
Included in #1909 ; merging that and closing this. |
Description of Changes
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 inim::HashMap
is likely possible, but it's at least very challenging and complex. Given that we no longer actually need the concurrent persistence offered byim::HashMap
, it seems easier to just revert to usingstd::collections::HashMap
.API and ABI breaking changes
Breaks SDK codegen. No user-facing breakage.
Expected complexity level and risk
2 - minor risk of deadlocks because the SDK's concurrency story is pretty complex, but well-tested so likely safe.
Testing