Add indices
field to _matchesPosition
to specify where in an array a match comes from
#5005
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request
Related issue
https:/orgs/meilisearch/discussions/550
What does this PR do?
This adds an
indices
fields to the objects returned in_matchesPosition
. The new field describes in what array element in the document the match was found. This was impossible before and users simply did not know where a match originated inside an array.Example document:
Searching for
cat
now returns this:Having
indices
be an array is required due to nested arrays, so one sometimes needs multiple indices to know what data the match comes from.Alternative API designs
An alternative design would be to include the indices inside the key of
_matchesPosition
, e.g.foo.bar[2].baz
. This is more intuitive to me and puts all "location inside document" information into one place, but has some disadvantages: the index needs to be parsed out of the key, which is annoying for end users. Also, JSON fields can have keys containing[2]
, so escaping would be necessary. Or one could insert.
dots before the[2]
(e.g.foo.bar.[2].baz
) which might make parsing easier.Another alternative could be to just include the full path inside the object, e.g.:
String elements would mean fields in an object, numbers would mean indices into an array. This is nice as all path information is in one place. This this, unlike with the current design (of this PR), you would also not need to know the document structure to understand at what levels the
indices
actually apply.Of course, the disadvantage is that there is duplication with the keys inside
_matchesPosition
. One could also convert_matchesPosition
to an array, but that's quite the breaking change and it would make some use cases more annoying.In summary: I personally am fine with all three designs. The implicit "you have to know where the indices go" of the current design is not too bad; the parsing of the
foo.bar[2].baz
approach also seems ok; adding the nicely typed full path also probably doesn't hurt too much thanks to compression. Let me know what you think! I can change this PR to switch to another approach.