Conversation
Companion to meilisearch/meilisearch#6187. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughDocumentation updates introducing Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
learn/filtering_and_sorting/geosearch.mdx (1)
55-69: Consider documenting acceptedlat/lngvalue types for_geo_listpoints.This section defines keys and array shape, but not whether
lat/lngaccept numeric strings like_geodoes. Adding that detail would make ingestion rules clearer.Based on learnings: "Documentation should be thorough, containing all information users need to use Meilisearch".
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@learn/filtering_and_sorting/geosearch.mdx` around lines 55 - 69, Clarify the accepted value types and validation rules for points in `_geo_list`: state that each entry must be an object with `lat` and `lng` keys that may be numbers or numeric strings (e.g., "48.8566") and will be parsed as floats, that lat must be between -90 and 90 and lng between -180 and 180, that the array must be non-empty when used to represent multiple locations, and that `null` or missing coordinates are ignored; update the `_geo_list` paragraph to include these type and range constraints and mention numeric-string parsing to match `_geo` behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@learn/filtering_and_sorting/geosearch.mdx`:
- Around line 75-82: Update the description of sorting with `_geoPoint` to
restrict “all geo fields” to only sortable geo fields by name; replace the
phrase with something like “all sortable geo fields (e.g., `_geo` and
`_geo_list`, excluding `_geojson`)” so it no longer contradicts the later note
that `_geojson` is ignored for sorting — change the sentence mentioning
`_geoPoint` accordingly in the geosearch documentation.
---
Nitpick comments:
In `@learn/filtering_and_sorting/geosearch.mdx`:
- Around line 55-69: Clarify the accepted value types and validation rules for
points in `_geo_list`: state that each entry must be an object with `lat` and
`lng` keys that may be numbers or numeric strings (e.g., "48.8566") and will be
parsed as floats, that lat must be between -90 and 90 and lng between -180 and
180, that the array must be non-empty when used to represent multiple locations,
and that `null` or missing coordinates are ignored; update the `_geo_list`
paragraph to include these type and range constraints and mention numeric-string
parsing to match `_geo` behavior.
| When filtering, a document matches if *any* point across all its geo fields falls within the specified area. When sorting with `_geoPoint`, Meilisearch uses the *closest* point from all geo fields. | ||
|
|
||
| When handling documents with both fields, Meilisearch: | ||
| When handling documents with multiple geo fields, Meilisearch: | ||
|
|
||
| - Ignores `_geojson` values when sorting | ||
| - Ignores `_geo` values when filtering with `_geoPolygon` | ||
| - Matches both `_geo` and `_geojson` values when filtering with `_geoRadius` and `_geoBoundingBox` | ||
| - Merges points from `_geo`, `_geojson`, and `_geo_list` when filtering with `_geoRadius` and `_geoBoundingBox` | ||
| - Merges points from `_geo` and `_geo_list` when sorting with `_geoPoint` |
There was a problem hiding this comment.
Clarify sorting scope to avoid contradiction with _geojson exclusion.
Line 75 says _geoPoint uses the closest point from “all geo fields,” but Line 79/82 says _geojson is ignored for sorting. Please narrow Line 75 wording to sortable geo fields only.
Suggested wording fix
-When sorting with `_geoPoint`, Meilisearch uses the *closest* point from all geo fields.
+When sorting with `_geoPoint`, Meilisearch uses the *closest* point from `_geo` and `_geo_list`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| When filtering, a document matches if *any* point across all its geo fields falls within the specified area. When sorting with `_geoPoint`, Meilisearch uses the *closest* point from all geo fields. | |
| When handling documents with both fields, Meilisearch: | |
| When handling documents with multiple geo fields, Meilisearch: | |
| - Ignores `_geojson` values when sorting | |
| - Ignores `_geo` values when filtering with `_geoPolygon` | |
| - Matches both `_geo` and `_geojson` values when filtering with `_geoRadius` and `_geoBoundingBox` | |
| - Merges points from `_geo`, `_geojson`, and `_geo_list` when filtering with `_geoRadius` and `_geoBoundingBox` | |
| - Merges points from `_geo` and `_geo_list` when sorting with `_geoPoint` | |
| When filtering, a document matches if *any* point across all its geo fields falls within the specified area. When sorting with `_geoPoint`, Meilisearch uses the *closest* point from `_geo` and `_geo_list`. | |
| When handling documents with multiple geo fields, Meilisearch: | |
| - Ignores `_geojson` values when sorting | |
| - Ignores `_geo` values when filtering with `_geoPolygon` | |
| - Merges points from `_geo`, `_geojson`, and `_geo_list` when filtering with `_geoRadius` and `_geoBoundingBox` | |
| - Merges points from `_geo` and `_geo_list` when sorting with `_geoPoint` |
🧰 Tools
🪛 LanguageTool
[style] ~76-~76: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...e closest point from all geo fields. When handling documents with multiple geo fi...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@learn/filtering_and_sorting/geosearch.mdx` around lines 75 - 82, Update the
description of sorting with `_geoPoint` to restrict “all geo fields” to only
sortable geo fields by name; replace the phrase with something like “all
sortable geo fields (e.g., `_geo` and `_geo_list`, excluding `_geojson`)” so it
no longer contradicts the later note that `_geojson` is ignored for sorting —
change the sentence mentioning `_geoPoint` accordingly in the geosearch
documentation.
1 participant
Summary
_geo_listreserved field for multi-point geosearch in the geosearch guide and documents reference_geo_listallows a single document to have multiple discrete geo points (e.g., a company with several offices)_geo_listsupportCompanion to meilisearch/meilisearch#6187.
Changes
learn/filtering_and_sorting/geosearch.mdx: Add_geo_listformat description, update the_geo/_geojsoninteraction note, update filtering and sorting configuration sections, update CSV limitationslearn/getting_started/documents.mdx: Mention_geo_listalongside_geoand_geojsonin the reserved attributes noteTest plan
_geo_listsection renders correctly🤖 Generated with Claude Code
Summary by CodeRabbit
Documentation
_geo_listfield support for documents with multiple locations