[OSDEV-1581] Add Geohex grid aggregation support to the production locations endpoint#488
Conversation
…rt-to-the-production-locations-endpoint
📝 WalkthroughWalkthroughThis pull request introduces Geohex grid aggregation support for the GET Changes
Possibly related PRs
Suggested reviewers
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/django/api/services/opensearch/search.py (1)
49-51: Consider adding type hints for better maintainability.The response dictionary creation could benefit from type hints:
- response_data = { + response_data: dict[str, Any] = { "count": total_hits, "data": data, }src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (1)
114-126: Consider making field names and boost values configurable.The multi-match query uses hardcoded field names and boost values. Consider moving these to class constants or configuration to improve maintainability.
+ MULTI_MATCH_FIELDS = [ + f'{V1_PARAMETERS_LIST.NAME}^2', + V1_PARAMETERS_LIST.ADDRESS, + V1_PARAMETERS_LIST.DESCRIPTION, + V1_PARAMETERS_LIST.LOCAL_NAME + ] + def __add_multi_match(self, query): self.query_body['query']['bool']['must'].append({ 'multi_match': { 'query': query, - 'fields': [ - f'{V1_PARAMETERS_LIST.NAME}^2', - V1_PARAMETERS_LIST.ADDRESS, - V1_PARAMETERS_LIST.DESCRIPTION, - V1_PARAMETERS_LIST.LOCAL_NAME - ], + 'fields': self.MULTI_MATCH_FIELDS, 'fuzziness': self.default_fuzziness } })src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py (1)
156-166: LGTM! Consider adding docstring to the new abstract method.The reorganization of abstract methods and addition of
add_specific_querieslooks good. To improve maintainability, consider adding a docstring to describe the expected behavior and parameters of the new abstract method.@abstractmethod def add_specific_queries(self, query_params): + """ + Process specific query parameters and add corresponding queries to the query body. + + Args: + query_params (dict): Dictionary containing query parameters to process + """ pass
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (15)
doc/release/RELEASE-NOTES.md(1 hunks)src/django/api/serializers/v1/production_locations_serializer.py(2 hunks)src/django/api/services/opensearch/search.py(1 hunks)src/django/api/tests/test_moderation_events_query_builder.py(1 hunks)src/django/api/tests/test_opensearch_response_formatter.py(1 hunks)src/django/api/tests/test_production_locations_query_builder.py(3 hunks)src/django/api/tests/test_v1_utils.py(6 hunks)src/django/api/views/v1/opensearch_query_builder/moderation_events_query_builder.py(1 hunks)src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py(1 hunks)src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py(1 hunks)src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py(1 hunks)src/django/api/views/v1/parameters_list.py(1 hunks)src/django/api/views/v1/utils.py(2 hunks)src/tests/v1/test_moderation_events.py(4 hunks)src/tests/v1/test_production_locations.py(1 hunks)
🧰 Additional context used
📓 Learnings (2)
src/django/api/views/v1/opensearch_query_builder/moderation_events_query_builder.py (1)
Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/views/v1/opensearch_query_builder/moderation_events_query_builder.py:48-0
Timestamp: 2024-11-12T09:11:37.544Z
Learning: In the `ModerationEventsQueryBuilder` class (`src/django/api/views/v1/opensearch_query_builder/moderation_events_query_builder.py`), methods inherited from the parent class `OpenSearchQueryBuilder`, such as `_build_os_id`, are available and can be used without redefining them.
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (1)
Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py:54-61
Timestamp: 2024-11-13T07:14:55.854Z
Learning: In the OpenSearch QueryBuilder classes (e.g., `ProductionLocationsQueryBuilder` in `src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py`), avoid introducing helper methods to keep the API of the query builder clear.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: run-integration-test-code-quality
- GitHub Check: run-django-code-quality
- GitHub Check: get-base-branch-django-cov
🔇 Additional comments (23)
src/django/api/views/v1/opensearch_query_builder/moderation_events_query_builder.py (1)
78-83: Implementation appears incomplete for Geohex grid aggregation support.The PR objectives indicate adding Geohex grid aggregation support, but this implementation is empty. If moderation events need to support grid aggregation queries similar to production locations, consider implementing the necessary query logic here.
Let's check if other query builders have implemented the grid aggregation support:
Would you like help implementing the Geohex grid aggregation support in this query builder? I can help generate the necessary query logic if required.
src/django/api/views/v1/parameters_list.py (1)
34-35: LGTM! Constants are well-defined.The new constants
AGGREGATIONandPRECISIONfollow the existing naming convention and align with the PR objectives.src/django/api/serializers/v1/production_locations_serializer.py (2)
28-29: Verify the necessity of address and description fields.These fields appear unrelated to the Geohex grid aggregation feature. Please clarify if they are part of a different requirement or should be in a separate PR.
50-58: LGTM! Well-structured validation for aggregation parameters.The implementation correctly:
- Restricts aggregation to 'hexgrid'
- Validates precision within range 0-15
- Makes both fields optional as per requirements
src/django/api/services/opensearch/search.py (1)
54-63: LGTM! Safe and clean implementation of aggregation data handling.The implementation:
- Safely extracts buckets using nested get() calls
- Maintains backward compatibility
- Only includes aggregation_data when buckets exist
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py (1)
101-101: LGTM! Good refactoring.The change improves code organization by delegating specific query handling to the appropriate builder classes, following the Single Responsibility Principle.
src/django/api/views/v1/utils.py (2)
38-40: LGTM! Parameters added for the new Geohex grid aggregation feature.The new parameters
PRECISIONandAGGREGATIONalign with the PR objectives.
57-57: Good improvement in error message formatting.Using
capitalize()instead oftitle()provides better readability for error messages by only capitalizing the first letter.Also applies to: 63-63, 67-68
src/django/api/tests/test_moderation_events_query_builder.py (1)
90-104: LGTM! Good test coverage for sorting functionality.The new tests thoroughly cover different sorting scenarios:
- Default order behavior
- Sorting by name field
- Sorting by address field
Each test follows good testing practices with clear assertions.
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (2)
102-113: LGTM! Good implementation of specific query handling.The method clearly handles both multi-match queries and aggregations.
102-147: Consider consolidating helper methods.Based on previous feedback (see retrieved learnings), helper methods should be avoided to keep the API clear. Consider consolidating the helper methods into the main methods.
Let's verify if there are similar patterns in other query builders:
src/django/api/tests/test_v1_utils.py (2)
45-47: LGTM! Good test coverage for new parameters.The test cases for
aggregationandprecisionparameters are well-structured and verify both the successful serialization and proper parameter values.Also applies to: 65-66
110-171: LGTM! Comprehensive error handling test coverage.The test cases thoroughly validate error handling for invalid aggregation and precision values, including:
- Invalid aggregation type
- Non-numeric precision
- Out-of-range precision values (both low and high)
src/django/api/tests/test_opensearch_response_formatter.py (1)
191-229: LGTM! Good test coverage for aggregation response handling.The test case thoroughly validates the handling of aggregation data in OpenSearch responses, including:
- Proper extraction of aggregation buckets
- Correct structure of the formatted response
- Absence of warning logs
src/django/api/tests/test_production_locations_query_builder.py (4)
170-173: LGTM! Good test for default sort order.The test verifies that the sort order defaults to ascending when not specified.
208-221: LGTM! Comprehensive test for multi-match query building.The test verifies the correct structure of multi-match queries, including:
- Field boosting (name^2)
- Multiple search fields
- Proper fuzziness setting
223-249: LGTM! Thorough testing of aggregation functionality.The tests cover both cases of aggregation configuration:
- With precision parameter
- Without precision parameter (default behavior)
251-290: LGTM! Good use of mocks for testing method interactions.The tests effectively use mocking to verify:
- Correct handling of aggregation parameters
- Proper precision parameter passing
- Query parameter processing
src/tests/v1/test_moderation_events.py (4)
149-149: LGTM! Error message standardizationThe error message has been standardized to use sentence case, improving consistency.
218-221: LGTM! Field name and error message standardizationThe changes improve consistency by:
- Using lowercase for field names (
date_gte)- Using sentence case for error messages
248-249: LGTM! Field name and error message standardizationThe changes improve consistency by:
- Using lowercase for field names (
country)- Using lowercase for country code in error message
275-276: LGTM! Field name and error message standardizationThe changes improve consistency by:
- Using lowercase for field names (
moderation_id)- Using lowercase for error message
doc/release/RELEASE-NOTES.md (1)
22-22: LGTM! Clear and detailed feature documentationThe release notes clearly document the new Geohex grid aggregation feature, including:
- The affected endpoint
- Required parameters and their values
- Optional parameters and their defaults
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py
Outdated
Show resolved
Hide resolved
protsack-stephan
left a comment
There was a problem hiding this comment.
Good work! Couple small comments from me.
src/django/api/serializers/v1/production_locations_serializer.py
Outdated
Show resolved
Hide resolved
src/django/api/serializers/v1/production_locations_serializer.py
Outdated
Show resolved
Hide resolved
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
src/django/api/serializers/v1/production_locations_serializer.py (2)
50-53: Consider adding docstring to explain the aggregation choices.While the implementation is correct, adding a docstring would help users understand the available aggregation options and their purposes.
54-58: Consider adding docstring to explain precision impact.The implementation correctly validates the precision range (0-15). However, adding a docstring would help users understand how different precision values affect the aggregation results.
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (1)
102-115: Consider renaming the method to better reflect its purpose.The method name
add_specific_queriesis vague. Consider a more descriptive name likeadd_search_and_aggregation_queriesto better reflect its functionality.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
doc/release/RELEASE-NOTES.md(1 hunks)src/django/api/serializers/v1/production_locations_serializer.py(2 hunks)src/django/api/services/opensearch/search.py(1 hunks)src/django/api/tests/test_production_locations_query_builder.py(3 hunks)src/django/api/tests/test_v1_utils.py(6 hunks)src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py(1 hunks)src/django/api/views/v1/parameters_list.py(1 hunks)src/django/api/views/v1/utils.py(2 hunks)src/tests/v1/test_production_locations.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
- src/django/api/views/v1/parameters_list.py
- src/django/api/views/v1/utils.py
- src/tests/v1/test_production_locations.py
- doc/release/RELEASE-NOTES.md
- src/django/api/services/opensearch/search.py
🧰 Additional context used
📓 Learnings (1)
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (1)
Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py:54-61
Timestamp: 2024-11-13T07:14:55.854Z
Learning: In the OpenSearch QueryBuilder classes (e.g., `ProductionLocationsQueryBuilder` in `src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py`), avoid introducing helper methods to keep the API of the query builder clear.
⏰ Context from checks skipped due to timeout of 90000ms (13)
- GitHub Check: run-integration-test-code-quality
- GitHub Check: run-flake8-linter
- GitHub Check: run-fe-code-quality
- GitHub Check: run-eslint-linter-and-prettier-formatter
- GitHub Check: run-django-code-quality
- GitHub Check: run-dd-code-quality
- GitHub Check: run-countries-code-quality
- GitHub Check: run-contricleaner-code-quality
- GitHub Check: get-base-branch-fe-cov
- GitHub Check: get-base-branch-dd-cov
- GitHub Check: get-base-branch-django-cov
- GitHub Check: get-base-branch-countries-cov
- GitHub Check: get-base-branch-contricleaner-cov
🔇 Additional comments (8)
src/django/api/serializers/v1/production_locations_serializer.py (1)
28-29: LGTM!The optional character fields for address and description are properly defined.
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (2)
116-128: LGTM!The multi-match implementation correctly handles field boosting and fuzziness.
130-149: 🛠️ Refactor suggestionRefactor to remove code duplication.
The method has duplicated aggregation configuration. Consider this improved implementation:
def __add_aggregations(self, aggregation, geohex_grid_precision=None): if aggregation == 'geohex_grid': - if not geohex_grid_precision: - self.query_body['aggregations'] = { - "grouped": { - "geohex_grid": { - "field": "coordinates", - } - } - } - else: - self.query_body['aggregations'] = { - "grouped": { - "geohex_grid": { - "field": "coordinates", - "precision": geohex_grid_precision - } - } - } + aggregation_config = { + "field": "coordinates" + } + if geohex_grid_precision is not None: + aggregation_config["precision"] = geohex_grid_precision + + self.query_body['aggregations'] = { + "grouped": { + "geohex_grid": aggregation_config + } + } return self.query_bodyLikely invalid or redundant comment.
src/django/api/tests/test_v1_utils.py (2)
45-47: LGTM!The test correctly validates the serialization of aggregation parameters.
Also applies to: 65-66
110-171: LGTM!Comprehensive test coverage for invalid scenarios:
- Invalid aggregation choice
- Invalid precision type
- Out-of-range precision values (both low and high)
src/django/api/tests/test_production_locations_query_builder.py (3)
170-173: LGTM!The test correctly verifies the default sort order behavior.
208-221: LGTM!The test thoroughly validates the multi-match query structure.
254-293: LGTM!The tests correctly use mocking to validate the interaction between methods.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/django/api/tests/test_production_locations_query_builder.py (2)
208-222: Consider testing through public interface instead of private method.While the test is thorough, testing private methods directly using name mangling (
_ProductionLocationsQueryBuilder__add_multi_match) is generally discouraged. Consider testing this functionality through the publicadd_specific_queriesmethod instead.
272-272: Fix typo in test method name.Change 'wit' to 'with' in the method name:
- def test_add_specific_queries_wit_aggregation_and_precision( + def test_add_specific_queries_with_aggregation_and_precision(
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/django/api/tests/test_opensearch_response_formatter.py(1 hunks)src/django/api/tests/test_production_locations_query_builder.py(3 hunks)src/tests/v1/test_production_locations.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/tests/v1/test_production_locations.py
- src/django/api/tests/test_opensearch_response_formatter.py
⏰ Context from checks skipped due to timeout of 90000ms (13)
- GitHub Check: run-flake8-linter
- GitHub Check: run-integration-test-code-quality
- GitHub Check: run-fe-code-quality
- GitHub Check: run-eslint-linter-and-prettier-formatter
- GitHub Check: run-django-code-quality
- GitHub Check: run-dd-code-quality
- GitHub Check: run-countries-code-quality
- GitHub Check: get-base-branch-fe-cov
- GitHub Check: run-contricleaner-code-quality
- GitHub Check: get-base-branch-dd-cov
- GitHub Check: get-base-branch-contricleaner-cov
- GitHub Check: get-base-branch-django-cov
- GitHub Check: get-base-branch-countries-cov
🔇 Additional comments (4)
src/django/api/tests/test_production_locations_query_builder.py (4)
170-174: LGTM! Well-structured test for default sorting behavior.The test properly verifies that the sort order defaults to 'asc' when no explicit order is specified.
223-240: LGTM! Test correctly verifies geohex grid aggregation with precision.The test properly validates the aggregation structure and the field name has been correctly updated to use 'precision' instead of 'geohex_grid_precision'.
241-253: LGTM! Test properly handles the case without precision.The test correctly verifies that the aggregation structure is properly formed when precision is not specified.
283-293: LGTM! Well-structured test for query parameter handling.The test properly verifies that the query parameter is correctly passed to the multi-match method.
…gregations instead
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
src/django/api/tests/test_production_locations_query_builder.py(2 hunks)src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py(1 hunks)src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py(2 hunks)src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/django/api/tests/test_production_locations_query_builder.py
🧰 Additional context used
📓 Learnings (1)
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (1)
Learnt from: VadimKovalenkoSNF
PR: opensupplyhub/open-supply-hub#391
File: src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py:54-61
Timestamp: 2024-11-13T07:14:55.854Z
Learning: In the OpenSearch QueryBuilder classes (e.g., `ProductionLocationsQueryBuilder` in `src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py`), avoid introducing helper methods to keep the API of the query builder clear.
⏰ Context from checks skipped due to timeout of 90000ms (13)
- GitHub Check: run-integration-test-code-quality
- GitHub Check: run-fe-code-quality
- GitHub Check: run-flake8-linter
- GitHub Check: run-eslint-linter-and-prettier-formatter
- GitHub Check: run-django-code-quality
- GitHub Check: run-countries-code-quality
- GitHub Check: run-dd-code-quality
- GitHub Check: run-contricleaner-code-quality
- GitHub Check: get-base-branch-fe-cov
- GitHub Check: get-base-branch-dd-cov
- GitHub Check: get-base-branch-contricleaner-cov
- GitHub Check: get-base-branch-django-cov
- GitHub Check: get-base-branch-countries-cov
🔇 Additional comments (4)
src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py (2)
102-114: LGTM! Well-structured multi-match implementation.The implementation correctly prioritizes name matches with field boosting (^2) and includes appropriate fuzziness for better search results.
116-131:⚠️ Potential issueAdd validation for geohex_grid_precision.
The geohex grid precision must be between 0 and 15, but this validation is missing.
Apply this diff to add validation:
def add_aggregations(self, aggregation, geohex_grid_precision=None): if aggregation == 'geohex_grid': + if geohex_grid_precision is not None: + try: + precision = int(geohex_grid_precision) + if not 0 <= precision <= 15: + raise ValueError("geohex_grid_precision must be between 0 and 15") + geohex_grid_precision = precision + except ValueError as e: + raise ValueError("Invalid geohex_grid_precision value") from e + aggregation_config = { 'field': 'coordinates' }Likely invalid or redundant comment.
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py (1)
34-45: LGTM! Well-structured query building process.The refactoring improves code readability and maintainability by breaking down the complex query building process into smaller, focused methods.
src/django/api/views/v1/opensearch_query_builder/opensearch_query_builder.py (1)
156-162: LGTM! Good use of abstract methods.Moving
add_multi_matchto the specific implementation and makingadd_sortandadd_termsabstract methods improves the design by:
- Ensuring that derived classes implement required functionality
- Keeping implementation-specific methods in their respective classes
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py
Show resolved
Hide resolved
|
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (13)
- GitHub Check: run-integration-test-code-quality
- GitHub Check: run-flake8-linter
- GitHub Check: run-fe-code-quality
- GitHub Check: run-eslint-linter-and-prettier-formatter
- GitHub Check: run-dd-code-quality
- GitHub Check: run-django-code-quality
- GitHub Check: run-countries-code-quality
- GitHub Check: run-contricleaner-code-quality
- GitHub Check: get-base-branch-fe-cov
- GitHub Check: get-base-branch-contricleaner-cov
- GitHub Check: get-base-branch-dd-cov
- GitHub Check: get-base-branch-django-cov
- GitHub Check: get-base-branch-countries-cov
🔇 Additional comments (2)
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py (2)
34-45: Well-structured refactoring of the build_query method!The modular approach with dedicated processing methods improves code organization and maintainability while following the Single Responsibility Principle.
132-133: Verify the builder's aggregation implementation.Ensure that the builder's
add_aggregationsmethod properly handles the geohex grid aggregation:✅ Verification successful
Implementation verified and properly tested ✅
The builder's
add_aggregationsmethod correctly implements geohex grid aggregation with:
- Proper handling of the
geohex_gridaggregation type- Support for optional precision parameter
- Comprehensive test coverage for both positive and negative cases
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the builder's aggregation implementation # Search for the add_aggregations method implementation echo "Searching for add_aggregations implementation..." ast-grep --pattern 'def add_aggregations($_, $_) { $$$ }' # Search for geohex grid related tests echo "Searching for related tests..." rg -l "geohex_grid" --type pyLength of output: 790
Script:
#!/bin/bash # Search for add_aggregations implementation with modified pattern echo "Searching for add_aggregations implementation..." ast-grep --pattern 'def add_aggregations' # Check the implementation echo "Checking implementation in production_locations_query_builder.py..." rg "add_aggregations" -A 10 src/django/api/views/v1/opensearch_query_builder/production_locations_query_builder.py # Check test coverage echo "Checking test coverage..." rg "test.*geohex.*grid" -A 5 src/django/api/tests/test_production_locations_query_builder.pyLength of output: 1211
Script:
#!/bin/bash # Check for positive geohex grid test cases echo "Checking positive test cases..." rg "test.*add.*aggregations.*geohex.*grid" -B 2 -A 15 src/django/api/tests/test_production_locations_query_builder.py # Check for any additional geohex grid related tests echo "Checking additional test cases..." rg "geohex_grid.*precision" -A 5 src/django/api/tests/test_production_locations_query_builder.pyLength of output: 1200
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py
Show resolved
Hide resolved
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py
Show resolved
Hide resolved
src/django/api/views/v1/opensearch_query_builder/opensearch_query_director.py
Show resolved
Hide resolved
VadimKovalenkoSNF
left a comment
There was a problem hiding this comment.
Looks good, approved.



OSDEV-1581 - [API] Add Geohex grid aggregation support to the production locations endpoint.
Added Geohex grid aggregation support to the GET
/api/v1/production-locations/endpoint. To receive the Geohex grid aggregation list in the response, it is necessary to pass theaggregationparameter with a value ofgeohex_gridand optionally specifygeohex_grid_precisionwith an integer between 0 and 15. Ifgeohex_grid_precisionis not defined, the default value of 5 will be used.Added test cases to cover the Geohex grid aggregation support.