Fixes #27482: Fix Advanced Search between boundaries for custom numerical properties#27486
Conversation
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
There was a problem hiding this comment.
Pull request overview
Fixes Advanced Search formatting for custom numeric property between filters by ensuring the full boundary array is passed through to the extension/customPropertiesTyped query builder, so Elasticsearch DSL can include both gte and lte.
Changes:
- Pass the complete
valuearray (instead ofvalue[0]) when building extension-field queries, allowingbetweento retain both bounds.
| return buildExtensionQuery( | ||
| extensionPropertyName, | ||
| entityType, | ||
| hasValue ? value[0] : null, | ||
| hasValue ? value : null, | ||
| op, | ||
| not | ||
| ); |
There was a problem hiding this comment.
This change fixes the range-boundary bug, but there’s no regression test covering the advanced-search → Elasticsearch DSL formatting for extension numeric properties with the between operator (i.e., verifying both gte and lte are emitted and change when the second boundary changes). Please add a unit test around elasticSearchFormatForJSONLogic/buildExtensionQuery for an extension.<entity>.<property> field using between to prevent this from regressing again.
|
hi maintainers could someone please add the |
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
aniruddhaadak80
left a comment
There was a problem hiding this comment.
Added explicit unit test for advanced-search extension numeric properties with the between operator as requested. Synced up with main.
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
| @@ -0,0 +1,45 @@ | |||
| import { elasticSearchFormatForJSONLogic } from './QueryBuilderElasticsearchFormatUtils'; | |||
There was a problem hiding this comment.
New test file is missing the standard Apache 2.0 license header block that other UI source/test files include (e.g., APIUtils.test.js). Please add the repository’s license header at the top of this file to satisfy license-header checks.
| }; | ||
|
|
||
| // The method elasticSearchFormatForJSONLogic internally uses tree.get() | ||
| const result = elasticSearchFormatForJSONLogic(tree, config); |
There was a problem hiding this comment.
This test calls elasticSearchFormatForJSONLogic(), but that function currently references an undeclared extendConfig (it isn’t imported/defined in QueryBuilderElasticsearchFormatUtils.js). In a Jest/module context this will throw and the catch block will return {}, making the assertions fail or the test not exercise the real formatting logic. Either switch the test to use elasticSearchFormat() (the function used by the app), or update elasticSearchFormatForJSONLogic to use extendConfigUtils.ConfigUtils.extendConfig like elasticSearchFormat does.
0974b36 to
0e77d3d
Compare
|
Hi there 👋 Thanks for your contribution! The OpenMetadata team will review the PR shortly! Once it has been labeled as Let us know if you need any help! |
Code Review ✅ Approved 2 resolved / 2 findingsRefactored Advanced Search logic to correctly handle boundaries for numerical properties, addressing fragile string matching and adding coverage for the missing not_between operator. ✅ 2 resolved✅ Quality: Test uses fragile string matching instead of structure assertions
✅ Edge Case: Missing test for not_between operator
OptionsDisplay: compact → Showing less information. Comment with these commands to change:
Was this helpful? React with 👍 / 👎 | Gitar |
Describe your changes:
Fixes #27482
I worked on QueryBuilderElasticsearchFormatUtils.js because the RAQB
betweenboundaries (i.e.[10, 20]) were incorrectly stripped of the upper bound duringbuildExtensionQuery. This passes the entire bounding Array correctly, repairing Advanced Search filtering.Type of change:
Checklist:
Fixes <issue-number>: <short explanation>Summary by Gitar
getFieldTypeInfoFromOmTypeandlookupOmPropertyTypeto use registry configuration for unambiguous field mapping.includes()toendsWith()to prevent misclassification of properties containing dots in their names.buildExtensionQueryby leveragingomPropertyTypemetadata instead of relying solely on value-shape parsing.This will update automatically on new commits.