Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SQL: Adjust the precision and scale for drivers #40467

Merged
merged 4 commits into from
Mar 27, 2019
Merged

Conversation

costin
Copy link
Member

@costin costin commented Mar 26, 2019

Fix #40357

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

@costin
Copy link
Member Author

costin commented Mar 26, 2019

@bpintea can you please double check the changes? Thanks!

KEYWORD( "keyword", JDBCType.VARCHAR, Integer.MAX_VALUE, 256, 0, false, false, true),
TEXT( "text", JDBCType.VARCHAR, Integer.MAX_VALUE, Integer.MAX_VALUE, 0, false, false, false),
SCALED_FLOAT( "scaled_float", JDBCType.DOUBLE, Integer.BYTES, 15, 25, false, true, true),
KEYWORD( "keyword", JDBCType.VARCHAR, Integer.MAX_VALUE, 256, 256,false, false, true),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if 256 is correct here. I think that's the default, but IIRC, this is a setting and thus could have a different (maximum) value. Treating KEYWORD as TEXT in this regard might be potentially safer?

It otherwise LGTM.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put 256 since I thought it was the default ignore_above value but I might be wrong:
https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html
You are right that it can be larger however I'm not sure what the default value should be - it's significantly smaller than that of text - seems like Short.MAX_VALUE-1 (32766) is the max.

@bpintea
Copy link
Contributor

bpintea commented Mar 26, 2019

LGTM.

if (t.isInteger()) {
return Short.valueOf((short) 0);
}
if (t.isRational()) {
if (t == DATETIME || t.isRational()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be: isDateBased().

Copy link
Contributor

@matriv matriv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments, also I would extract the 32766 to a constant.

KEYWORD( "keyword", JDBCType.VARCHAR, Integer.MAX_VALUE, 256, 0, false, false, true),
TEXT( "text", JDBCType.VARCHAR, Integer.MAX_VALUE, Integer.MAX_VALUE, 0, false, false, false),
SCALED_FLOAT( "scaled_float", JDBCType.DOUBLE, Integer.BYTES, 15, 25, false, true, true),
KEYWORD( "keyword", JDBCType.VARCHAR, Integer.MAX_VALUE, 256, 32766,false, false, true),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing whitespace after 32766

@@ -175,7 +175,7 @@ public static Integer metaSqlDataType(DataType t) {
}

// https://github.com/elastic/elasticsearch/issues/30386
// https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgettypeinfo-function?view=sql-server-2017
// https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgettypeinfo-function
public static Integer metaSqlDateTimeSub(DataType t) {
if (t == DATETIME) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here: isDateBased()?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was skipped but shouldn't be changed too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so since the type info indicates it should be just for datetime (timestamp) not DATE or TIME

SCALED_FLOAT( "scaled_float", JDBCType.FLOAT, Double.BYTES, 19, 25, false, true, true),
KEYWORD( "keyword", JDBCType.VARCHAR, Integer.MAX_VALUE, 256, 0, false, false, true),
TEXT( "text", JDBCType.VARCHAR, Integer.MAX_VALUE, Integer.MAX_VALUE, 0, false, false, false),
SCALED_FLOAT( "scaled_float", JDBCType.DOUBLE, Integer.BYTES, 15, 25, false, true, true),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is Integer.BYTES correct here? because the comment above says: precision is based on long

Copy link
Contributor

@astefan astefan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@costin costin merged commit 1557d77 into elastic:master Mar 27, 2019
@costin costin deleted the fix-40357 branch March 27, 2019 12:14
costin added a commit that referenced this pull request Mar 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SQL: floats precision and scale corrections
6 participants