Skip to content
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

[Feature Request]: Match shape of return type to shape of parameter types #2494

Open
AlabasterAxe opened this issue Jul 10, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@AlabasterAxe
Copy link
Contributor

AlabasterAxe commented Jul 10, 2024

Describe the problem

This issue relates to #2492 but it's not exactly the same. This issue raises the question of what the behavior of a function that accepts both singular and array requests should be with respect to its return type.

For example, let's say hypothetically, the queryRecords interface accepts either a string or an array of strings as its queryTexts property.

const resp = client.queryRecords(collection, {
  queryTexts: ["query text", "query text 2"],
  nResults: 2,
});

// Resp equals:
//   {
//     ids: [["id1", "id2"], ["id3", "id4"]],
//     embeddings: [[[1,2,3], [4,5,6]], [[7,8,9],[10,11,12]]],
//     documents: [["document 1", "document 2"], ["document 3", "document 4"]],
//     metadatas: [[null, null], [null, null]],
//     distances: [[.7,.8], [.2,.6]],
//   }

const resp = client.queryRecords(collection, {
  queryTexts: "query text",
  nResults: 2,
});

// Resp equals: ?

Describe the proposed solution

I would argue that for someone working with the client, it's more convenient to unwrap the arrays. Given a singular string request, it's not possible for there to be more than one entry in each of the arrays so we can save the client the unnecessary boiler plate of extracting the 0th element. The principle here is that the client matches the shape of the supplied argument. So the shape of the response would be:

// Resp equals:
//   {
//     ids: ["id1", "id2"],
//     embeddings: [[1,2,3], [4,5,6]],
//     documents: ["document 1", "document 2"],
//     metadatas: [null, null],
//     distances: [1,2],
//   }

I'm not proposing we always unwrap responses that have a single element in them though. For example, if the caller supplied us with an array that had a single element in it, I think that the right behavior is the behavior below:

const resp = client.queryRecords(collection, {
  queryTexts: ["query text"],
  nResults: 2,
});

// Resp equals:
//   {
//     ids: [["id1", "id2"]],
//     embeddings: [[[1,2,3], [4,5,6]]],
//     documents: [["document 1", "document 2"]],
//     metadatas: [[null, null]],
//     distances: [[.7,.8]],
//   }

Again, the principle here being that we're matching the shape of the supplied query. Since the caller provided us with an array, we return them an array of responses, even though there's only a single element.

Alternatives considered

The alternative here is to do what we do today which would be:

const resp = client.queryRecords(collection, {
  queryTexts: "query text",
  nResults: 2,
});

// Resp equals:
//   {
//     ids: [["id1", "id2"]],
//     embeddings: [[[1,2,3], [4,5,6]]],
//     documents: [["document 1", "document 2"]],
//     metadatas: [[null, null]],
//     distances: [[1,2]],
//   }

The benefit of this approach is that the shape of the response is always consistent with itself. That said, I would argue that consistency between the input and the output of the function is more important than consistency across calls to a function.

Importance

nice to have

Additional Information

No response

@AlabasterAxe AlabasterAxe added the enhancement New feature or request label Jul 10, 2024
@AlabasterAxe AlabasterAxe changed the title [Feature Request]: Match return types to call types [Feature Request]: Match return types to parameter types Jul 10, 2024
@AlabasterAxe AlabasterAxe changed the title [Feature Request]: Match return types to parameter types [Feature Request]: Match shape of return type to shape of parameter types Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant