Implement custom types for inference and control plane #46
Conversation
src/pinecone/control.rs
Outdated
| /// use pinecone_sdk::utils::errors::PineconeError; | ||
| /// | ||
| /// # #[tokio::main] | ||
| /// # async fn main() -> Result<(), PineconeError>{ | ||
| /// let pinecone = PineconeClient::new(None, None, None, None).unwrap(); | ||
| /// | ||
| /// // List all indexes in the project. | ||
| /// let index_list_response: Result<IndexList, PineconeError> = pinecone.list_indexes().await; | ||
| /// let index_list_response = pinecone.list_indexes().await; |
There was a problem hiding this comment.
I included the type here previously to be clear about what is being returned, is there a reason for removing it?
There was a problem hiding this comment.
I thought we previously said not to include it in docstrings examples and only to include it in the README example, but I may be remembering wrong and I'm okay adding it back
src/models/embeddings_list.rs
Outdated
| /// The embeddings generated by the model. | ||
| pub data: Vec<Vec<f32>>, |
There was a problem hiding this comment.
I think we should still have types to represent the Embedding, since in the future we will introduce other responses alongside values like a sparse embedding that will have a different type than Vec<f32>
There was a problem hiding this comment.
I guess when we cross that bridge we may find ourselves wanting to re-type these fields as Optional, but let's keep it simple for now.
There was a problem hiding this comment.
This looks good to me, but would like to have input from @austin-denoble and @haruska
src/models/openapi.rs
Outdated
| CollectionList, CollectionModel, ConfigureIndexRequest, ConfigureIndexRequestSpec, | ||
| ConfigureIndexRequestSpecPod, CreateCollectionRequest, DeletionProtection, | ||
| EmbedRequestParameters, IndexModelSpec, IndexModelStatus, IndexSpec, PodSpec, | ||
| PodSpecMetadataConfig, ServerlessSpec, |
There was a problem hiding this comment.
In Rust, does this essentially re-export these models from the models module for easier organization?
We do something similar in TypeScript with mixing generated types and custom types.
There was a problem hiding this comment.
Yes, outside the sdk you'd be able to import these openapi types through pinecone::models instead of the openapi folder. The openapi types are still accessible through pinecone::openapi::<type> though because we need to be able to access them from the sibling module, but I can see if there's a way to change that in a follow-up to this PR.
Problem
Currently, the SDK uses the generated types, however some of these are difficult to use from the user perspective (poorly defined, multiple versions defined, etc).
Solution
We implement a custom
EmbeddingsListUsage,EmbeddingsList,IndexList,IndexModel, andMetrictype in amodelsdirectory. We also export allopenapitypes to the same directory so that the imports will all be consistent.Type of Change
Test Plan
Test cases should pass.