Improve processing OpenSearch data types. Fix using subfields for `text` type. #299

Yury-Fridlyand · 2023-07-19T02:20:59Z

Description

See doc for technical details: https://github.com/Bit-Quill/opensearch-project-sql/blob/dev-add-text-type/docs/dev/text-type.md
See also this comment describing some changes.

Issues Resolved

Pass full types (instances of OpenSearchDataType) though :core module instead of simplified ones (ExprCoreType).
This unblocks access to important mapping info such as text fields or date formats. This info is required to build proper DSL queries to OpenSearch.
Use text fields instead of hardcoded keyword subfield name.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

docs/dev/img/type-hierarchy-tree-final.png

core/src/main/java/org/opensearch/sql/expression/operator/convert/TypeCastOperator.java

docs/dev/query-type-conversion.md

integ-test/src/test/java/org/opensearch/sql/sql/TextTypeIT.java

GumpacG · 2023-07-25T22:31:42Z

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchTextType.java

    }
-    return fieldName;
+    // Pick first field. What to do if there are multiple fields?


Can you pass in the type like how it was with convertTextToKeyword and map that type by finding it in the list of fields?

Is it needed?
Now this function isn't static and different types may overload it if needed. Having that we can avoid creating a new function like convertXXXtoYYY in future.

Right. But how would it know which type to convert to? For example, doing aggregation on text with mapping

"textColumn": { "type": "text", "fields": { "date": { "type": "date" }, "keyword": { "type": "keyword" } } } }

will do aggregation on textColumn.date. What would be expected here?

I'm with @GumpacG on this.

keyword field is a convention in OpenSearch to mean "first bit of the text" and conversion is "ok, I guess" for legacy's sake but in general picking the first field would lead to unexpected results that depend on the mapping.

On the other hand, if fielddata is set then it is safe to use textColumn field in this place.

It is possible to aggregate on dates inside a text field.
I changed to find a string subfield if present in 8b0671c.

Signed-off-by: Yury-Fridlyand <[email protected]>

docs/dev/query-type-conversion.md

acarbonetto

For docs/dev/img/type-hierarchy-tree-final.png:

Can you split STRING into TEXT and KEYWORD?
Can you align DATE and TIME
I'm not sure you want STRING --> DATE/TIME/DATETIME/TIMESTAMP since its a very specific set of strings that convert. I think that conversion is 'special' and doesn't need to be defined here.

core/src/main/java/org/opensearch/sql/expression/operator/convert/TypeCastOperator.java

docs/dev/query-type-conversion.md

acarbonetto · 2023-07-24T16:08:11Z

docs/dev/query-type-conversion.md

+
+## Final type hierarchy scheme
+
+![Most relevant type hierarchy](img/type-hierarchy-tree-final.png)


There's only STRING in that listing. Should we specify TEXT vs KEYWORD there?

There is no TEXT nor KEYWORD in ExprCoreType.

matthewryanwells · 2023-07-27T17:44:40Z

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java

+  }
+
+  public int hashCode() {
+    return 42 + exprCoreType.hashCode();


Would this be considered a magic number that should be defined as a constant?

Maybe https://xkcd.com/221/

Why is this override necessary?

This is needed to make OpenSearchExprValueFactory::typeActionMap work properly. Without that override it always falls to

opensearch-project-sql/opensearch/src/main/java/org/opensearch/sql/opensearch/data/value/OpenSearchExprValueFactory.java

Lines 208 to 210 in 5232ad2

throw new IllegalStateException(

String.format(

"Unsupported type: %s for value: %s.", type.typeName(), content.objectValue()));

This could be simplified to always return 0 (or any other constant) to enforce equals check always.

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java

acarbonetto · 2023-07-27T17:49:34Z

docs/dev/text-type.md

+
+## Solution
+
+The solution is to provide to `:core` non simplified types, but full types. Those objects should be fully compatible with `ExprCoreType` and implement all required APIs to allow `:core` to manipulate with built-in functions. Once those type objects are returned back to `:opensearch`, it can get all required information to build the correct search request.


non simplified types: enum
full types: Objects
right?
Can we just say that?

simplified types: enum
full types: Objects

Before full types were converted to enums before passing from :opensearch to :core. With my changes full types are passed from :opensearch to :core, and :core uses an API call to convert them to a enum value whatever it is needed (to pick proper function signature).

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java

acarbonetto · 2023-07-27T17:56:30Z

opensearch/src/test/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataTypeTest.java

+            OpenSearchDataType.of(MappingType.GeoPoint)),
+        () -> assertNotEquals(OpenSearchDataType.of(MappingType.GeoPoint),
+            OpenSearchDataType.of(MappingType.Ip)),
+        () -> assertEquals(OpenSearchDataType.of(STRING), OpenSearchDataType.of(STRING)),


I don't understand the purpose of this test

c for coverage
I had to add 4 tests to satisfy jacoco caprise for line 42 and 4 more tests for line 43

opensearch-project-sql/opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java

Lines 42 to 43 in 5232ad2

if (mappingType != null && other.mappingType != null) {

return mappingType.equals(other.mappingType) && exprCoreType.equals(other.exprCoreType);

opensearch/src/test/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataTypeTest.java

Signed-off-by: Yury-Fridlyand <[email protected]>

MaxKsyunz

Have you considered creating one class hierarchy for types? Instead of ExprCoreTypes being enum values, make them classes and derive from each other as appropriate.

Singleton instances can still be used for types that do not have parameters, like ints, keyword, etc.
This would simplify a lot of the type comparison logic.

MaxKsyunz · 2023-07-27T20:54:49Z

core/src/main/java/org/opensearch/sql/data/type/ExprType.java

@@ -21,7 +20,8 @@ public interface ExprType {
   * Is compatible with other types.
   */
  default boolean isCompatible(ExprType other) {
-    if (this.equals(other)) {
+    // Do double direction check with `equals`, because a derived class may override it
+    if (this.equals(other) || other.equals(this)) {


By definition, if this.equals(other) then other.equals(this) must be true.

Do we have ExprTypes for which this is necessary? If yes, the problem is there.

other maybe an instance of OpenSearchDataType, which has more complex comparison logic.
I have an idea how to fix it, will do soon.

Fixed in b04a92e.

MaxKsyunz · 2023-07-27T20:58:27Z

integ-test/src/test/java/org/opensearch/sql/ppl/DataTypeIT.java

@@ -36,8 +36,8 @@ public void test_numeric_data_types() throws IOException {
        schema("byte_number", "byte"),
        schema("double_number", "double"),
        schema("float_number", "float"),
-        schema("half_float_number", "float"),
-        schema("scaled_float_number", "double"));
+        schema("half_float_number", "half_float"),


Why is this change necessary?

This caused by changes described in #299 (comment)

MaxKsyunz · 2023-07-27T20:58:42Z

integ-test/src/test/java/org/opensearch/sql/ppl/DataTypeIT.java

+        schema("object_value", "object"),
+        schema("nested_value", "nested"),


Why is this change necessary?

This caused by changes described in #299 (comment)

MaxKsyunz · 2023-07-27T20:59:43Z

integ-test/src/test/java/org/opensearch/sql/ppl/SystemFunctionIT.java

@@ -56,19 +56,18 @@ public void typeof_opensearch_types() throws IOException {
        + " | fields `double`, `long`, `integer`, `byte`, `short`, `float`, `half_float`, `scaled_float`",
            TEST_INDEX_DATATYPE_NUMERIC));
    verifyDataRows(response,
-        rows("DOUBLE", "LONG", "INTEGER", "BYTE", "SHORT", "FLOAT", "FLOAT", "DOUBLE"));
+        rows("DOUBLE", "LONG", "INTEGER", "BYTE", "SHORT", "FLOAT", "HALF_FLOAT", "SCALED_FLOAT"));


How does this relate to adding text type?

This caused by changes described in #299 (comment)

MaxKsyunz · 2023-07-27T21:06:25Z

opensearch/src/test/java/org/opensearch/sql/opensearch/data/type/OpenSearchDateTypeTest.java

+        () -> assertEquals("TIMESTAMP", defaultDateType.typeName()),
+        () -> assertEquals("TIME", timeDateType.typeName()),
        () -> assertEquals("DATE", dateDateType.typeName()),
-        () -> assertEquals("DATE", datetimeDateType.typeName())
+        () -> assertEquals("TIMESTAMP", datetimeDateType.typeName())


This looks very unrelated to adding text type.

Before

OpenSearchDateType converted to a simplified type when passed to :core module. Actually, ExprCoreType extracted from OSDT, it is stored inside. Values were DATE/TIME/etc.

ExprCoreType names used to build schema in QueryResponse, which was serialized later and sent to user. legacyTypeName method of ExprType used for SQL responses and typeName for PPL ones.

In the middle

OSDT isn't converted

Same methods of OSDT return mappingType which is always date regardless of detected ExprCoreType for this field.

Finally

-//-

OpenSearchDateType overrides these methods to return ExprCoreType

No changes for a user!

MaxKsyunz · 2023-07-27T21:29:23Z

core/src/main/java/org/opensearch/sql/data/type/ExprType.java

+  /**
+   * Perform field name conversion if needed before inserting it into a search query.
+   */
+  default String convertFieldForSearchQuery(String fieldName) {
+    return fieldName;
+  }
+
+  /**
+   * Perform value conversion if needed before inserting it into a search query.
+   */
+  default Object convertValueForSearchQuery(ExprValue value) {
+    return value.value();
+  }


It'd be more appropriate for these to be on OpenSearchDataType since they are specific to how we communicate with OpenSearch.

Unfortunately, where it is used, ExprType is referenced. I'd like to avoid excessive refactoring there.

opensearch-project-sql/opensearch/src/main/java/org/opensearch/sql/opensearch/storage/script/filter/lucene/LikeQuery.java

Lines 16 to 19 in 6c3744e

public class LikeQuery extends LuceneQuery {

@Override

public QueryBuilder doBuild(String fieldName, ExprType fieldType, ExprValue literal) {

String field = OpenSearchTextType.convertTextToKeyword(fieldName, fieldType);

Any ideas how to do it gracefully?

MaxKsyunz · 2023-07-27T21:30:57Z

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java

+  }
+
+  public int hashCode() {
+    return 42 + exprCoreType.hashCode();


Why is this override necessary?

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java

MaxKsyunz · 2023-07-27T21:43:04Z

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java

@@ -163,8 +208,8 @@ public static OpenSearchDataType of(MappingType mappingType, Map<String, Object>
      case Ip: return OpenSearchIpType.of();
      case Date:
        // Default date formatter is used when "" is passed as the second parameter
-        String format = (String) innerMap.getOrDefault("format", "");
-        return OpenSearchDateType.of(format);
+        return innerMap.isEmpty() ? OpenSearchDateType.of()


Why change this?

This simplifies creation of OpenSearchDateType. A format string passes a number of checks even when it is empty.

MaxKsyunz · 2023-07-27T21:49:25Z

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchTextType.java

-      return fieldName + ".keyword";
+  @Override
+  public String convertFieldForSearchQuery(String fieldName) {
+    if (fields.size() == 0) {


In this case the user will end up with OpenSearch error about not being able to aggregate on text. Do I get that right?

Yury-Fridlyand · 2023-07-28T02:30:42Z

For docs/dev/img/type-hierarchy-tree-final.png:

...

@acarbonetto
I listed all current ExprCoreType possible widenings according to the code.

Signed-off-by: Yury-Fridlyand <[email protected]>

Yury-Fridlyand requested review from MitchellGale and matthewryanwells July 19, 2023 02:20

This comment was marked as spam.

Sign in to view

Yury-Fridlyand mentioned this pull request Jul 21, 2023

[FEATURE] Add new data type for text opensearch-project/sql#1038

Open

GumpacG reviewed Jul 25, 2023

View reviewed changes

Yury-Fridlyand added 7 commits July 25, 2023 18:46

Add text type.

2136ae8

Signed-off-by: Yury-Fridlyand <[email protected]>

Simplify implementation.

bb9f30e

Signed-off-by: Yury-Fridlyand <[email protected]>

Add docs.

33370ff

Signed-off-by: Yury-Fridlyand <[email protected]>

Add IT.

5b2a659

Signed-off-by: Yury-Fridlyand <[email protected]>

Fix type resolution in IT.

ccf9138

Signed-off-by: Yury-Fridlyand <[email protected]>

Code clean up and comment update.

0339320

Signed-off-by: Yury-Fridlyand <[email protected]>

Minor clean up.

e885a44

Signed-off-by: Yury-Fridlyand <[email protected]>

Yury-Fridlyand force-pushed the dev-add-text-type branch from 554a460 to e885a44 Compare July 26, 2023 01:48

Yury-Fridlyand added 3 commits July 27, 2023 10:12

Update ExprType and tests.

93e9a34

Signed-off-by: Yury-Fridlyand <[email protected]>

Minor fix in docs.

d3b66ac

Signed-off-by: Yury-Fridlyand <[email protected]>

Finalize implementation and tests.

5232ad2

Signed-off-by: Yury-Fridlyand <[email protected]>

Yury-Fridlyand marked this pull request as ready for review July 27, 2023 17:16

Yury-Fridlyand requested review from MaxKsyunz, forestmvey and acarbonetto as code owners July 27, 2023 17:16

matthewryanwells reviewed Jul 27, 2023

View reviewed changes

docs/dev/query-type-conversion.md Outdated Show resolved Hide resolved

acarbonetto reviewed Jul 27, 2023

View reviewed changes

matthewryanwells reviewed Jul 27, 2023

View reviewed changes

opensearch/src/main/java/org/opensearch/sql/opensearch/data/type/OpenSearchDataType.java Outdated Show resolved Hide resolved

acarbonetto reviewed Jul 27, 2023

View reviewed changes

matthewryanwells approved these changes Jul 27, 2023

View reviewed changes

Smart subfield selection.

8b0671c

Signed-off-by: Yury-Fridlyand <[email protected]>

MaxKsyunz reviewed Jul 28, 2023

View reviewed changes

Address PR feedback.

b04a92e

Signed-off-by: Yury-Fridlyand <[email protected]>

Merge remote-tracking branch 'upstream/main' into dev-add-text-type

efcb86e

Signed-off-by: Yury-Fridlyand <[email protected]>

Yury-Fridlyand changed the title ~~Add text type.~~ Improve processing OpenSearch data types. Fix using subfields for text type. Aug 15, 2023

Yury-Fridlyand merged commit 96285bf into integ-add-text-type Aug 21, 2023
18 of 20 checks passed

Yury-Fridlyand deleted the dev-add-text-type branch August 21, 2023 17:45

Yury-Fridlyand mentioned this pull request Aug 21, 2023

Improve processing OpenSearch data types. Fix using subfields for text type. opensearch-project/sql#2003

Open

6 tasks


		## Final type hierarchy scheme

		![Most relevant type hierarchy](img/type-hierarchy-tree-final.png)

	throw new IllegalStateException(
	String.format(
	"Unsupported type: %s for value: %s.", type.typeName(), content.objectValue()));


		## Solution

		The solution is to provide to `:core` non simplified types, but full types. Those objects should be fully compatible with `ExprCoreType` and implement all required APIs to allow `:core` to manipulate with built-in functions. Once those type objects are returned back to `:opensearch`, it can get all required information to build the correct search request.

	if (mappingType != null && other.mappingType != null) {
	return mappingType.equals(other.mappingType) && exprCoreType.equals(other.exprCoreType);

		schema("object_value", "object"),
		schema("nested_value", "nested"),

	public class LikeQuery extends LuceneQuery {
	@Override
	public QueryBuilder doBuild(String fieldName, ExprType fieldType, ExprValue literal) {
	String field = OpenSearchTextType.convertTextToKeyword(fieldName, fieldType);

Improve processing OpenSearch data types. Fix using subfields for text type. #299

Improve processing OpenSearch data types. Fix using subfields for text type. #299

Conversation

Yury-Fridlyand commented Jul 19, 2023 • edited Loading

Description

Issues Resolved

Check List

This comment was marked as spam.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acarbonetto left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MaxKsyunz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Before

In the middle

Finally

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Yury-Fridlyand commented Jul 28, 2023

Improve processing OpenSearch data types. Fix using subfields for `text` type. #299

Improve processing OpenSearch data types. Fix using subfields for `text` type. #299

Yury-Fridlyand commented Jul 19, 2023 •

edited

Loading