v1.14: Get documents by ids

[guimachiavelli]

Closes #3190

[meili-bot]

How to see the preview of this PR?

⚠️ Private link, only accessible to Meilisearch employees.

Go to this URL: https://website-git-deploy-preview-mei-16-meili.vercel.app/docs/branch:3190-v1.14-get-documents-by-id

Credentials to access the page are in the company's password manager as "Docs deploy preview".

[dureuill]

Good 👍

1. do we want to specify somewhere the behavior when passing both ids and filter, or do you think it is easy enough to comprehend given their individual behaviors?

2. do we want to specify somewhere that passing a non-existing id does not cause an error, but simply does not return a document for the non-existing id?

[guimachiavelli]

do we want to specify somewhere the behavior when passing both ids and filter, or do you think it is easy enough to comprehend given their individual behaviors?

I would say it's easy enough to understand, yeah. I'm not sure what other behaviour someone could expect from using the two together.

do we want to specify somewhere that passing a non-existing id does not cause an error, but simply does not return a document for the non-existing id?

I thought about that, but it also felt a bit self-evident when compared to the behaviour of other parameters across the application. For example, if you e.g. set a filter for rating > 3 in /documents or /search, or try to find tasks before e.g. 1970 and Meilisearch doesn't find any matches, it will return no documents or tasks.

---

So I'm inclined not to mention those directly unless we have any direct feedback from users struggling with either/both behaviours.

[dureuill]

Thank you for the answer.

For the record, we almost designed the API to return an error when a docid with no matching document was in the list of ids.

Another behavior we considered for passing both ids and filter was to OR the two filters (currently it is an AND), that is, Meilisearch would have returned all the documents with the requested ids plus all documents matching the filter (in the implementation, Meilisearch returns the documents with requested ids that also match the filter)

[guimachiavelli]

That's very interesting. I think returning an error for fetching non-existent ids is reasonable (though I'd still feel surprised because in most scenarios I can think of we usually don't do that), but returning all documents matching ids plus all documents matching the filters would be unexpected. Still, this could all be my personal bias as someone who's not actively implementing Meilisearch in production.

I personally think the final result is more intuitive than the other avenues you looked into, but I'll discuss it with the product team and see if we can find a way to monitor the situation here in case I'm wrong.