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.
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.
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