ids
to POST /indexes/INDEX_UID/documents/fetch
ids
is added as an optional parameter to the body of requests made against POST /indexes/INDEX_UID/documents/fetch
.ids
default to null
, and the behavior of Meilisearch v1.13 is preserved.ids
, but in an internal order. This is for performance reasons, and for consistency with the order of returned documents when only filter
is present. The internal order remains consistent between calls to POST /indexes/INDEX_UID/documents/fetch
as long as no index modification takes place between the calls.ids
and filter
are present and non-null
, then the set of possibly returned documents is the intersection of the documents that match the filter and the documents whose document id is contained in ids
.ids
respect the limit
and offset
parameters. That is, if the list contains 6 ids, limit is set to 3, and offset is set to 0, then only the first three documents (according to the internal order) will be returned. The same request with offset set to 3 will return the last three documents.Getting a list of documents
// POST /indexes/INDEX_UID/documents/fetch
{
"ids": ["cody", "finn", "brandy", "gambit"]
}
{
"results": [
{
// documents are not returned in the queried order
"id": "brandy",
"info": 13765493
},
{
"id": "finn",
"info": 35863
},
{
"id": "cody",
"info": 122263
},
{
"id": "gambit",
"info": 22222
}
],
"offset": 0,
"limit": 20,
"total": 4
}
Mixing filter
and ids
// POST /indexes/INDEX_UID/documents/fetch
{
"ids": ["cody", "finn", "brandy", "gambit"],
"filter": "info > 100000"
}
{
"results": [
{
// documents are not returned in the queried order
"id": "brandy",
"info": 13765493
},
{
"id": "cody",
"info": 122263
}
],
"offset": 0,
"limit": 20,
"total": 2
}