-
Notifications
You must be signed in to change notification settings - Fork 179
Description
History
Nowadays most of the user queries are processed by our enhanced SQL engine v2. Initially, as part of our migration plan, we added a plugin setting in case users want to opt out. As more and more features migrated to v2, the setting was removed to avoid confusion in OpenSearch 1.0.
Problem
Recently we found there is still minor discrepancy in certain case that user will see inconsistent query behavior. This may caused by special index name, field name or statement/functions yet to migrate. For reference, see recent issues labeled legacy. To improve customer experience, I think we need to deprecate legacy code as soon as possible.
Approach
Fortunately SQL has good test coverage of both unit test and integration test. All integration test runs against both SQL engine v2 and legacy. It is easy to identify the gaps by failing the test directly without fallback.
Known Gaps and Priority
Any gap in fundamental elements should be prioritized:
- Identifier name: index and field
- Data type and literal format: ex. date format
- Basic SQL functions
- OpenSearch data types: ip, geo point etc
- OpenSearch aggregate functions
Query and other statement unsupported in v2 can migrate later:
- Nested field query by PartiQL
- JOIN query: nested loop and hash join
- Set operation: ex. intersect/union/union all
- Delete statement
- Pagination
Issues related:
- Issues identified by TDVT: https://github.com/opensearch-project/sql/issues?q=is%3Aissue+is%3Aopen+label%3Atdvt
- Issues due to fallback to legacy code: https://github.com/opensearch-project/sql/issues?q=is%3Aissue+is%3Aopen+label%3Alegacy