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.
We recently had a contribution to the Go SDK to add this API, and I realized it would be useful to have it here in the Rust SDK now for integration with the query engine. So, this PR introduces a new API:
ContainerClient::get_feed_ranges
which returns aVec<FeedRange>
which describes the current physical partition layout. Like in other SDKs,FeedRange
s map on to Partition Key Range IDs, but we don't expose the actual range IDs to the user, so that when a user specifies FeedRanges somewhere, we can adapt the ranges to the current partition topology (adjusting based on merges/splits, etc.).Internally, we also have a
ContainerClient::get_partition_key_ranges
which uses the/pkranges
REST API to fetch the full Partition Key Range metadata. This is used in the query engine, which already has to be updated with merge/split awareness and needs the exact PKRangeID for issuing queries. This API isn't part of the public surface area.The model type returned by
get_partition_key_ranges
isPartitionKeyRange
and that struct is part of the public surface area. It has to be in order to put it on theQueryEngine
abstraction. But there's no way, using our public APIs, for a user to get the actual PK Range IDs from the REST API, nor do any of our APIs acceptPartitionKeyRange
objects. With a little bit of#[cfg]
fiddling, I may actually be able to make it so these APIs are only public in thepreview_query_engine
feature, which is the only place we actually need them to be exported outside the crate.This PR also adjusts the
QueryEngine
API to take the Partition Key Ranges as objects, since now the Rust SDK itself has the model and APIs to deserialize them. Before, it was passing the PKRanges as raw JSON and the query engine did the deserializing. This just removes some code duplication. I'll update the query engine to fix this shortly.