-
Notifications
You must be signed in to change notification settings - Fork 49
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
Update v1.7.0 - implementation #81
Conversation
@@ -663,6 +687,58 @@ impl QdrantClient { | |||
.await?) | |||
} | |||
|
|||
pub async fn create_shard_key( | |||
&self, | |||
collection_name: impl AsRef<str>, |
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.
We use impl ToString
in a lot of other places, but I think impl AsRef<str>
is a lot better in this case. Since this is a new function, I choose to use this better one here.
We could also remove all function parameters and imply provide a CreateShardKeyRequest
. Not sure which is better.
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.
Can you explain why you think AsRef
is better in this case?
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.
I thought I already answered this, but somehow my answer is missing 😄
Anyway, in this case: AsRef
allows 1 string clone, ToString
requires 2 string clones.
pub async fn upsert_points( | ||
&self, | ||
collection_name: impl ToString, | ||
shard_key_selector: Option<Vec<shard_key::Key>>, | ||
points: Vec<PointStruct>, | ||
ordering: Option<WriteOrdering>, | ||
) -> Result<PointsOperationResponse> { |
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.
I put the shard_key_selector
right after collection_name
. Seems to make sense to me. But we could also add it as last parameter, any opinions?
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.
Make another function with this parameter, to not overload default functions with arguments?
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.
We can do that, but that would duplicate a whole lot of them (and we already have duplication for some blocking/non-blocking calls).
Maybe we can use some form of builder pattern in the future.
Looks good 👍 I am only missing the user perspective on the shard selector:
|
Construct the
No. Good idea. |
These now work: ShardKeySelector::from(1);
ShardKeySelector::from("a");
ShardKeySelector::from(vec![1, 2, 3]);
ShardKeySelector::from(vec!["a".to_string(), "b".to_string()]);
ShardKeySelector::from(vec!["a", "b"]); |
FYI I updated one my project to use this branch. |
* Add create and delete shard key functions * Use more direct shard key types * Add discovery functions * Conversions from borrowed types into sparse vectors * Add shard key selector parameter to all relevant API functions * Move shard key selector parameter adjacent collection name parameter * Update documentation example * Add conversion helpers for shard key selector * sync proto * proto changes * fix readme --------- Co-authored-by: generall <[email protected]>
Tasks
create_shard_key
delete_shard_key
discover
discover_batch
From<Vec<(_, _)>>
➡️From<&[(_, _)]>
because we construct new Vecs anywayTasks after merging
All Submissions:
dev
branch. Did you create your branch fromdev
?New Feature Submissions:
cargo +nightly fmt --all
command prior to submission?cargo clippy --all --all-features
command?