[jira] [Commented] (CALCITE-4910) Enhance simplify to reduce ((a or d) and (a or c) and a and b) to (a and b)
[
https://issues.apache.org/jira/browse/CALCITE-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468412#comment-17468412
]
Ziwei Liu commented on CALCITE-4910:
I have submit the code
[https://github.com/apache/calcite/pull/2673]
Please review the code when you available.
> Enhance simplify to reduce ((a or d) and (a or c) and a and b) to (a and b)
> ---
>
> Key: CALCITE-4910
> URL: https://issues.apache.org/jira/browse/CALCITE-4910
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ziwei Liu
>Assignee: Ziwei Liu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Considering this condition, (a or d) and (a or c) and a and b. This condition
> can be simplified to a and b, but now simplify can not do this.
> This case is found out by materialized view test:
> {code:java}
> materialized view:
> select 'a',empid,deptno,salary as s from emps where (replace(name,'e','a') is
> not null or replace(name,'a','c') is not null)
> and (replace(name,'c','b') is not null or replace(name,'n','d') is not null)
> sql:
> select salary +1 as s,deptno from emps where
> replace(name,'c','b')is not null and replace(name,'a','c') is not null and
> salary>10
> The sql will not be rewritten by materialized view because when splitFilter,
> $3 > 10 and REPLACE($2, 'a', 'c') is not null and REPLACE($2, 'c', 'b') is
> not null and (REPLACE($2, 'a', 'c') is not null or REPLACE($2, 'e', 'a') is
> not null)
> and (REPLACE($2, 'c', 'b') is not null or REPLACE($2, 'n', 'd') is not null)
> can not be simplified to
> $3 > 10 and REPLACE($2, 'a', 'c') is not null and REPLACE($2, 'c', 'b') is
> not null
> materialized view:
> select empid,deptno,salary as s from emps where
> (replace(name,'e','a') ='aaa' or replace(name,'a','c') ='aaa')
> and
> (replace(name,'c','b') ='aaa' or replace(name,'n','d') ='aaa')
> sql:
> select salary as s,deptno from emps where
> replace(name,'c','b') ='aaa' is not null
> and replace(name,'a','c') ='aaa'
> This case also can not be rewritten.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4910) Enhance simplify to reduce ((a or d) and (a or c) and a and b) to (a and b)
[
https://issues.apache.org/jira/browse/CALCITE-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4910:
Labels: pull-request-available (was: )
> Enhance simplify to reduce ((a or d) and (a or c) and a and b) to (a and b)
> ---
>
> Key: CALCITE-4910
> URL: https://issues.apache.org/jira/browse/CALCITE-4910
> Project: Calcite
> Issue Type: Improvement
>Reporter: Ziwei Liu
>Assignee: Ziwei Liu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Considering this condition, (a or d) and (a or c) and a and b. This condition
> can be simplified to a and b, but now simplify can not do this.
> This case is found out by materialized view test:
> {code:java}
> materialized view:
> select 'a',empid,deptno,salary as s from emps where (replace(name,'e','a') is
> not null or replace(name,'a','c') is not null)
> and (replace(name,'c','b') is not null or replace(name,'n','d') is not null)
> sql:
> select salary +1 as s,deptno from emps where
> replace(name,'c','b')is not null and replace(name,'a','c') is not null and
> salary>10
> The sql will not be rewritten by materialized view because when splitFilter,
> $3 > 10 and REPLACE($2, 'a', 'c') is not null and REPLACE($2, 'c', 'b') is
> not null and (REPLACE($2, 'a', 'c') is not null or REPLACE($2, 'e', 'a') is
> not null)
> and (REPLACE($2, 'c', 'b') is not null or REPLACE($2, 'n', 'd') is not null)
> can not be simplified to
> $3 > 10 and REPLACE($2, 'a', 'c') is not null and REPLACE($2, 'c', 'b') is
> not null
> materialized view:
> select empid,deptno,salary as s from emps where
> (replace(name,'e','a') ='aaa' or replace(name,'a','c') ='aaa')
> and
> (replace(name,'c','b') ='aaa' or replace(name,'n','d') ='aaa')
> sql:
> select salary as s,deptno from emps where
> replace(name,'c','b') ='aaa' is not null
> and replace(name,'a','c') ='aaa'
> This case also can not be rewritten.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4971) update httpclient and httpcore to latest 5.1 release
[ https://issues.apache.org/jira/browse/CALCITE-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated CALCITE-4971: - Description: Apache commons httpclient/httpcomponent 4.5 depend on commons-logging and not slf4j. This means that phoenix-thin requires explicit log4j configuration to work. We want all logging to go through SLF4j, and to be able to use any supported backend. Based on an an offline conversation with [~elserj] As these are new major version, it's probably going to involve more than a version bump. was: Apache commons httpclient/httpcomponent 4.5 depend on commons-logging and not slf4j. This means that phoenix-thin requires explicit log4j configuration to work. We want all logging to go through SLF4j, and to be able to use any supported backend. Based on an an offline conversation with [~elserj] Summary: update httpclient and httpcore to latest 5.1 release (was: Update org.apache.httpcomponents:httpclient to latest) > update httpclient and httpcore to latest 5.1 release > > > Key: CALCITE-4971 > URL: https://issues.apache.org/jira/browse/CALCITE-4971 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Priority: Major > > Apache commons httpclient/httpcomponent 4.5 depend on commons-logging and not > slf4j. This means that phoenix-thin requires explicit log4j configuration to > work. > We want all logging to go through SLF4j, and to be able to use any supported > backend. > Based on an an offline conversation with [~elserj] > As these are new major version, it's probably going to involve more than a > version bump. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CALCITE-4962) Protobuf debug does not show request/response type
[
https://issues.apache.org/jira/browse/CALCITE-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
duan xiong resolved CALCITE-4962.
-
Fix Version/s: avatica-1.21.0
Resolution: Fixed
> Protobuf debug does not show request/response type
> --
>
> Key: CALCITE-4962
> URL: https://issues.apache.org/jira/browse/CALCITE-4962
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Marco Jorge
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.21.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> _(nicetities first - great project and thanks all for the great work)_
> The ProtobufTranslationImpl is able to debug the content of the messages
> encoded/decoded but it does not show the request/response type which is
> critical to identify abnormal situations.
> The current output is:
> {code:java}
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b" info { key:
> "password" value: "" } info { key: "user" value: "" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'metadata { server_address:
> "container-queryengine-tenant-be62-1792c303378a-677fcbfcc7-kvlz5:8080" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b" conn_props {
> is_dirty: true auto_commit: true has_auto_commit: true }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'conn_props { auto_commit: true has_auto_commit: true has_read_only:
> true } metadata { server_address:
> "container-queryengine-tenant-be62-1792c303378a-677fcbfcc7-kvlz5:8080" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b"'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'props { key { name: "GET_NUMERIC_FUNCTIONS" } value { type: STRING
> string_value:
> "ABS,ACOS,ASIN,ATAN,ATAN2,CBRT,CEILING,COS,COT,DEGREES,EXP,FLOOR,LOG,LOG10,MOD,PI,POWER,RADIANS,RAND,ROUND,SIGN,SIN,SQRT,TAN,TRUNCATE"
> } } props { key { name: "GET_S_Q_L_KEYWORDS" } value { type: STRING
> string_value:
> "ABS,ALLOW,ARRAY,ARRAY_MAX_CARDINALITY,ASENSITIVE,ASYMMETRIC,ATOMIC,BEGIN_FRAME,BEGIN_PARTITION,BIGINT,BINARY,BLOB,BOOLEAN,CALLED,CARDINALITY,CEIL,CEILING,CLASSIFIER,CLOB,COLLECT,CORR,COVAR_POP,COVAR_SAMP,CUBE,CUME_DIST,CURRENT_CATALOG,CURRENT_DEFAULT_TRANSFORM_GROUP,CURRENT_ROLE,CURRENT_ROW,CURRENT_SCHEMA,CURRENT_TRANSFORM_GROUP_FOR_TYPE,CYCLE,DEFINE,DENSE_RANK,DEREF,DISALLOW,DYNAMIC,EACH,ELEMENT,EMPTY,END-EXEC,END_FRAME,END_PARTITION,EQUALS,EVERY,EXP,EXPLAIN,EXTEND,FILTER,FIRST_VALUE,FLOOR,FRAME_ROW,FREE,FUSION,GROUPING,GROUPS,HOLD,IMPORT,INITIAL,INTERSECTION,JSON_ARRAY,JSON_ARRAYAGG,JSON_EXISTS,JSON_OBJECT,JSON_OBJECTAGG,JSON_QUERY,JSON_VALUE,LAG,LARGE,LAST_VALUE,LATERAL,LEAD,LIKE_REGEX,LIMIT,LN,LOCALTIME,LOCALTIMESTAMP,MATCHES,MATCH_NUMBER,MATCH_RECOGNIZE,MEASURES,MEMBER,MERGE,METHOD,MINUS,MOD,MODIFIES,MULTISET,NCLOB,NEW,NONE,NORMALIZE,NTH_VALUE,NTILE,OCCURRENCES_REGEX,OFFSET,OLD,OMIT,ONE,OVER,OVERLAY,PARTITION,PATTERN,PER,PERCENT,PERCENTILE_CONT,PERCENTILE_DISC,PERCENT_RANK,PERIOD,PERMUTE,PORTION,POSITION_REGEX,POWER,PRECEDES,PREV,RANGE,RANK,READS,RECURSIVE,REF,REFERENCING,REGR_AVGX,REGR_AVGY,REGR_COUNT,REGR_INTERCEPT,REGR_R2,REGR_SLOPE,REGR_SXX,REGR_SXY,REGR_SYY,RELEASE,RESET,RESULT,ROLLUP,ROW,ROW_NUMBER,RUNNING,SAVEPOINT,SCOPE,SEARCH,SEEK,SENSITIVE,SHOW,SIMILAR,SKIP,SPECIFICTYPE,SQRT,START,STATIC,STDDEV_POP,STDDEV_SAMP,STREAM,SUBMULTISET,SUBSET,SUBSTRING_REGEX,SUCCEEDS,SYMMETRIC,SYSTEM,SYSTEM_TIME,TABLESAMPLE,TINYINT,TRANSLATE_REGEX,TREAT,TRIGGER,TRIM_ARRAY,TRUNCATE,UESCAPE,UNNEST,UPSERT,VALUE_OF,VARBINARY,VAR_POP,VAR_SAMP,VERSIONING,WIDTH_BUCKET,WINDOW,WITHIN,WITHOUT"
> } } props { key { name: "GET_DEFAULT_TRANSACTION_ISOLATION" } value { type:
> INTEGER } } props { key { name: "GET_TIME_DATE_FUNCTIONS" } value { type:
> STRING string_value:
> "CONVERT_TIMEZONE,CURDATE,CURTIME,DAYNAME,DAYOFMONTH,DAYOFWEEK,DAYOFYEAR,HOUR,MINUTE,MONTH,MONTHNAME,NOW,QUARTER,SECOND,TIMESTAMPADD,TIMESTAMPDIFF,TO_DATE,TO_TIMESTAMP,WEEK,YEAR"
> } } props { key { name: "GET_DRIVER_MAJOR_VERSION" } value { type: INTEGER
> number_value: 1 } } props { key { name: "GET_DRIVER_VERSION" } value { type:
> STRING string_value: "1.27.0" } } props { key { name:
> "GET_DATABASE_PRODUCT_VERSION" } value { type: STRING string_value: "1.27.0"
> } } props { key { name: "GET_SYSTEM_FUNCTIONS" } value { type: STRING
> string_value: "CONVERT,DATABASE,IFNULL,USER" } } props { key { name:
> "GET_STRING_FUNCTIONS" } value { type: STRING string_value:
>
[jira] [Commented] (CALCITE-4962) Protobuf debug does not show request/response type
[
https://issues.apache.org/jira/browse/CALCITE-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468310#comment-17468310
]
duan xiong commented on CALCITE-4962:
-
Fixed in
[e9d14a6|https://github.com/apache/calcite-avatica/commit/e9d14a684a54cadc0d6feca2b8aae08e7152a705].
Thanks for your PR [~marcobjorge] .
> Protobuf debug does not show request/response type
> --
>
> Key: CALCITE-4962
> URL: https://issues.apache.org/jira/browse/CALCITE-4962
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Marco Jorge
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> _(nicetities first - great project and thanks all for the great work)_
> The ProtobufTranslationImpl is able to debug the content of the messages
> encoded/decoded but it does not show the request/response type which is
> critical to identify abnormal situations.
> The current output is:
> {code:java}
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b" info { key:
> "password" value: "" } info { key: "user" value: "" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'metadata { server_address:
> "container-queryengine-tenant-be62-1792c303378a-677fcbfcc7-kvlz5:8080" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b" conn_props {
> is_dirty: true auto_commit: true has_auto_commit: true }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'conn_props { auto_commit: true has_auto_commit: true has_read_only:
> true } metadata { server_address:
> "container-queryengine-tenant-be62-1792c303378a-677fcbfcc7-kvlz5:8080" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b"'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'props { key { name: "GET_NUMERIC_FUNCTIONS" } value { type: STRING
> string_value:
> "ABS,ACOS,ASIN,ATAN,ATAN2,CBRT,CEILING,COS,COT,DEGREES,EXP,FLOOR,LOG,LOG10,MOD,PI,POWER,RADIANS,RAND,ROUND,SIGN,SIN,SQRT,TAN,TRUNCATE"
> } } props { key { name: "GET_S_Q_L_KEYWORDS" } value { type: STRING
> string_value:
> "ABS,ALLOW,ARRAY,ARRAY_MAX_CARDINALITY,ASENSITIVE,ASYMMETRIC,ATOMIC,BEGIN_FRAME,BEGIN_PARTITION,BIGINT,BINARY,BLOB,BOOLEAN,CALLED,CARDINALITY,CEIL,CEILING,CLASSIFIER,CLOB,COLLECT,CORR,COVAR_POP,COVAR_SAMP,CUBE,CUME_DIST,CURRENT_CATALOG,CURRENT_DEFAULT_TRANSFORM_GROUP,CURRENT_ROLE,CURRENT_ROW,CURRENT_SCHEMA,CURRENT_TRANSFORM_GROUP_FOR_TYPE,CYCLE,DEFINE,DENSE_RANK,DEREF,DISALLOW,DYNAMIC,EACH,ELEMENT,EMPTY,END-EXEC,END_FRAME,END_PARTITION,EQUALS,EVERY,EXP,EXPLAIN,EXTEND,FILTER,FIRST_VALUE,FLOOR,FRAME_ROW,FREE,FUSION,GROUPING,GROUPS,HOLD,IMPORT,INITIAL,INTERSECTION,JSON_ARRAY,JSON_ARRAYAGG,JSON_EXISTS,JSON_OBJECT,JSON_OBJECTAGG,JSON_QUERY,JSON_VALUE,LAG,LARGE,LAST_VALUE,LATERAL,LEAD,LIKE_REGEX,LIMIT,LN,LOCALTIME,LOCALTIMESTAMP,MATCHES,MATCH_NUMBER,MATCH_RECOGNIZE,MEASURES,MEMBER,MERGE,METHOD,MINUS,MOD,MODIFIES,MULTISET,NCLOB,NEW,NONE,NORMALIZE,NTH_VALUE,NTILE,OCCURRENCES_REGEX,OFFSET,OLD,OMIT,ONE,OVER,OVERLAY,PARTITION,PATTERN,PER,PERCENT,PERCENTILE_CONT,PERCENTILE_DISC,PERCENT_RANK,PERIOD,PERMUTE,PORTION,POSITION_REGEX,POWER,PRECEDES,PREV,RANGE,RANK,READS,RECURSIVE,REF,REFERENCING,REGR_AVGX,REGR_AVGY,REGR_COUNT,REGR_INTERCEPT,REGR_R2,REGR_SLOPE,REGR_SXX,REGR_SXY,REGR_SYY,RELEASE,RESET,RESULT,ROLLUP,ROW,ROW_NUMBER,RUNNING,SAVEPOINT,SCOPE,SEARCH,SEEK,SENSITIVE,SHOW,SIMILAR,SKIP,SPECIFICTYPE,SQRT,START,STATIC,STDDEV_POP,STDDEV_SAMP,STREAM,SUBMULTISET,SUBSET,SUBSTRING_REGEX,SUCCEEDS,SYMMETRIC,SYSTEM,SYSTEM_TIME,TABLESAMPLE,TINYINT,TRANSLATE_REGEX,TREAT,TRIGGER,TRIM_ARRAY,TRUNCATE,UESCAPE,UNNEST,UPSERT,VALUE_OF,VARBINARY,VAR_POP,VAR_SAMP,VERSIONING,WIDTH_BUCKET,WINDOW,WITHIN,WITHOUT"
> } } props { key { name: "GET_DEFAULT_TRANSACTION_ISOLATION" } value { type:
> INTEGER } } props { key { name: "GET_TIME_DATE_FUNCTIONS" } value { type:
> STRING string_value:
> "CONVERT_TIMEZONE,CURDATE,CURTIME,DAYNAME,DAYOFMONTH,DAYOFWEEK,DAYOFYEAR,HOUR,MINUTE,MONTH,MONTHNAME,NOW,QUARTER,SECOND,TIMESTAMPADD,TIMESTAMPDIFF,TO_DATE,TO_TIMESTAMP,WEEK,YEAR"
> } } props { key { name: "GET_DRIVER_MAJOR_VERSION" } value { type: INTEGER
> number_value: 1 } } props { key { name: "GET_DRIVER_VERSION" } value { type:
> STRING string_value: "1.27.0" } } props { key { name:
> "GET_DATABASE_PRODUCT_VERSION" } value { type: STRING string_value: "1.27.0"
> } } props { key { name: "GET_SYSTEM_FUNCTIONS" } value { type: STRING
> string_value: "CONVERT,DATABASE,IFNULL,USER" } } props {
[jira] [Commented] (CALCITE-4972) Subfields of array columns containing structs are not qualified in getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468285#comment-17468285
]
Mark Grey commented on CALCITE-4972:
Thanks Julian. Given that javadoc explicitly stated the length of the returned
list to be four, I wanted to confirm my understanding was correct before filing
this as a bug. Changed the issue type and summary per your feedback.
I'd like to have a try at addressing this if you feel there's potential in
either of the approaches described (or something another path I should
explore). Thanks!
> Subfields of array columns containing structs are not qualified in
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value currently is:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4972) Subfields of array columns containing structs are not qualified in getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Grey updated CALCITE-4972:
---
Issue Type: Bug (was: Improvement)
> Subfields of array columns containing structs are not qualified in
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value currently is:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4972) Subfields of array columns containing structs are not qualified in getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Grey updated CALCITE-4972:
---
Summary: Subfields of array columns containing structs are not qualified in
getFieldOrigins (was: Qualify subfields of array columns containing structs in
return of getFieldOrigins)
> Subfields of array columns containing structs are not qualified in
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value currently is:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4972) Qualify subfields of array columns containing structs in return of getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Grey updated CALCITE-4972:
---
Description:
Attempting to follow on the [suggestions from Julian in this
thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l], found
a potential improvement.
Given a table schema containing a repeated array of structs and a query
projecting fields of that struct via UNNEST, the present implementation of
{{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
suggesting that the subfield is actually a member of the top level table row
type.
For example, when using the [DEPT_NESTED table from the
MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
within tests with the following query:
{code:sql}
select e.empno from dept_nested, unnest(employees) as e
{code}
The return value currently is:
{code:java}
{CATALOG.SALES.DEPT_NESTED.EMPNO}
{code}
Rather than:
{code:java}
{CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
{code}
No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
[The javadoc for the method
|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
suggests that the return from this method should always be four entries long,
although it would seem this doesn't account for nesting. Is this intended
behavior, or should {{column}} entry of this list be of variable length?
was:
Attempting to follow on the [suggestions from Julian in this
thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l], found
a potential improvement.
Given a table schema containing a repeated array of structs and a query
projecting fields of that struct via UNNEST, the present implementation of
{{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
suggesting that the subfield is actually a member of the top level table row
type.
For example, when using the [DEPT_NESTED table from the
MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
within tests with the following query:
{code:sql}
select e.empno from dept_nested, unnest(employees) as e
{code}
The return value will be:
{code}
{CATALOG.SALES.DEPT_NESTED.EMPNO}
{code}
Rather than:
{code}
{CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
{code}
No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
[The javadoc for the method
|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
suggests that the return from this method should always be four entries long,
although it would seem this doesn't account for nesting. Is this intended
behavior, or should {{column}} entry of this list be of variable length?
> Qualify subfields of array columns containing structs in return of
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value currently is:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
[jira] [Commented] (CALCITE-4972) Qualify subfields of array columns containing structs in return of getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468272#comment-17468272
]
Julian Hyde commented on CALCITE-4972:
--
Your wording "The return value will be" is a little misleading, depending on
whether you read this as a bug or a feature request.
I agree with you that the return value is currently
"{CATALOG.SALES.DEPT_NESTED.EMPNO}" and should be
"{CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}".
> Qualify subfields of array columns containing structs in return of
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value will be:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4972) Qualify subfields of array columns containing structs in return of getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468272#comment-17468272
]
Julian Hyde edited comment on CALCITE-4972 at 1/3/22, 11:45 PM:
Your wording "The return value will be" is a little misleading, depending on
whether you read this as a bug or a feature request.
I agree with you that the return value is currently
"CATALOG.SALES.DEPT_NESTED.EMPNO" and should be
"CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO".
was (Author: julianhyde):
Your wording "The return value will be" is a little misleading, depending on
whether you read this as a bug or a feature request.
I agree with you that the return value is currently
"{CATALOG.SALES.DEPT_NESTED.EMPNO}" and should be
"{CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}".
> Qualify subfields of array columns containing structs in return of
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value will be:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4963) Extensibility of SqlDialectFactory lacks reusability of SqlDialectFactoryImpl.*
[ https://issues.apache.org/jira/browse/CALCITE-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-4963. -- Fix Version/s: 1.30.0 Resolution: Fixed Fixed in [8983e7e8|https://github.com/apache/calcite/commit/8983e7e82ef65c3a72f06305a676cc2998bf72d6]; thanks for the PR, [~marcobjorge]! > Extensibility of SqlDialectFactory lacks reusability of > SqlDialectFactoryImpl.* > --- > > Key: CALCITE-4963 > URL: https://issues.apache.org/jira/browse/CALCITE-4963 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Marco Jorge >Priority: Major > Labels: pull-request-available > Fix For: 1.30.0 > > Time Spent: 40m > Remaining Estimate: 0h > > _(nicetities first - great project and thanks all for the great work)_ > Although it's possible to extend the SqlDialectFactory, the custom > implementation cannot reuse any of the behaviour of the default > SqlDialectFactoryImpl. The default SqlDialectFactoryImpl has lots of > important/reusable behaviour such as #getCasing, #isCaseSensitive, > #getNullCollation or even the default decisioning in the #create method. > If any user needs to provide a custom SqlDialect yet still support the > existing SqlDialects the user needs to copy the whole SqlDialectFactoryImpl > to make the custom changes. > This request is to make the default behavior in SqlDialectFactoryImpl > reusable so that extensions don't need to fork a whole class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4972) Qualify subfields of array columns containing structs in return of getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468201#comment-17468201
]
Mark Grey edited comment on CALCITE-4972 at 1/3/22, 9:05 PM:
-
Assuming that a fully qualified return is desirable in this case, I was able to
get a naive fix working by checking if the namespace could unwrap to
{{UnnestNamespace}} in {{SqlValidatorImpl}} and if so, using the identifiers
within to qualify the sub fields in the return.
It seems like a poor approach however, and that rather than changing the output
of this method specifically after the fact it would be better to construct the
{{Step}} and {{Path}} to account for the nesting during validation.
was (Author: mgthesecond):
Assuming that a fully qualified return is desirable in this case, I was able to
get a naive fix working by checking if the namespace could unwrap to
{{UnnestNamespace}} in {{SqlValidatorImpl}} and if so, using the identifiers
within to qualify the sub fields in the return.
It seems like a poor approach however, and that rather than changing the output
of this method specifically after the fact it would be better to construct the
{{Step}} s and {{Path}} to account for the nesting during validation.
> Qualify subfields of array columns containing structs in return of
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value will be:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4972) Qualify subfields of array columns containing structs in return of getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468201#comment-17468201
]
Mark Grey commented on CALCITE-4972:
Assuming that a fully qualified return is desirable in this case, I was able to
get a naive fix working by checking if the namespace could unwrap to
{{UnnestNamespace}} in {{SqlValidatorImpl}} and if so, using the identifiers
within to qualify the sub fields in the return.
It seems like a poor approach however, and that rather than changing the output
of this method specifically after the fact it would be better to construct the
{{Step}}s and {{Path}} to account for the nesting during validation.
> Qualify subfields of array columns containing structs in return of
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value will be:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4972) Qualify subfields of array columns containing structs in return of getFieldOrigins
[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468201#comment-17468201
]
Mark Grey edited comment on CALCITE-4972 at 1/3/22, 9:05 PM:
-
Assuming that a fully qualified return is desirable in this case, I was able to
get a naive fix working by checking if the namespace could unwrap to
{{UnnestNamespace}} in {{SqlValidatorImpl}} and if so, using the identifiers
within to qualify the sub fields in the return.
It seems like a poor approach however, and that rather than changing the output
of this method specifically after the fact it would be better to construct the
{{Step}} s and {{Path}} to account for the nesting during validation.
was (Author: mgthesecond):
Assuming that a fully qualified return is desirable in this case, I was able to
get a naive fix working by checking if the namespace could unwrap to
{{UnnestNamespace}} in {{SqlValidatorImpl}} and if so, using the identifiers
within to qualify the sub fields in the return.
It seems like a poor approach however, and that rather than changing the output
of this method specifically after the fact it would be better to construct the
{{Step}}s and {{Path}} to account for the nesting during validation.
> Qualify subfields of array columns containing structs in return of
> getFieldOrigins
> --
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.28.0
>Reporter: Mark Grey
>Priority: Minor
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value will be:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4971) Update org.apache.httpcomponents:httpclient to latest
[ https://issues.apache.org/jira/browse/CALCITE-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468197#comment-17468197 ] Josh Elser commented on CALCITE-4971: - Thanks for filing, Istvan, and thanks for clarifying things, Julian. > Update org.apache.httpcomponents:httpclient to latest > -- > > Key: CALCITE-4971 > URL: https://issues.apache.org/jira/browse/CALCITE-4971 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Priority: Major > > Apache commons httpclient/httpcomponent 4.5 depend on commons-logging and not > slf4j. This means that phoenix-thin requires explicit log4j configuration to > work. > We want all logging to go through SLF4j, and to be able to use any supported > backend. > Based on an an offline conversation with [~elserj] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CALCITE-4972) Qualify subfields of array columns containing structs in return of getFieldOrigins
Mark Grey created CALCITE-4972:
--
Summary: Qualify subfields of array columns containing structs in
return of getFieldOrigins
Key: CALCITE-4972
URL: https://issues.apache.org/jira/browse/CALCITE-4972
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.28.0
Reporter: Mark Grey
Attempting to follow on the [suggestions from Julian in this
thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l], found
a potential improvement.
Given a table schema containing a repeated array of structs and a query
projecting fields of that struct via UNNEST, the present implementation of
{{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
suggesting that the subfield is actually a member of the top level table row
type.
For example, when using the [DEPT_NESTED table from the
MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
within tests with the following query:
{code:sql}
select e.empno from dept_nested, unnest(employees) as e
{code}
The return value will be:
{code}
{CATALOG.SALES.DEPT_NESTED.EMPNO}
{code}
Rather than:
{code}
{CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
{code}
No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
[The javadoc for the method
|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
suggests that the return from this method should always be four entries long,
although it would seem this doesn't account for nesting. Is this intended
behavior, or should {{column}} entry of this list be of variable length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4963) Extensibility of SqlDialectFactory lacks reusability of SqlDialectFactoryImpl.*
[ https://issues.apache.org/jira/browse/CALCITE-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468151#comment-17468151 ] Julian Hyde commented on CALCITE-4963: -- I'm now reviewing and testing, and plan to merge shortly. I plan to change the summary to 'Make it easier to sub-class SqlDialectFactoryImpl' and add a note about the new 'SqlDialects.createContext' method. Also, I'll rename 'context' back to 'c' to minimize code changes. > Extensibility of SqlDialectFactory lacks reusability of > SqlDialectFactoryImpl.* > --- > > Key: CALCITE-4963 > URL: https://issues.apache.org/jira/browse/CALCITE-4963 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Marco Jorge >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > _(nicetities first - great project and thanks all for the great work)_ > Although it's possible to extend the SqlDialectFactory, the custom > implementation cannot reuse any of the behaviour of the default > SqlDialectFactoryImpl. The default SqlDialectFactoryImpl has lots of > important/reusable behaviour such as #getCasing, #isCaseSensitive, > #getNullCollation or even the default decisioning in the #create method. > If any user needs to provide a custom SqlDialect yet still support the > existing SqlDialects the user needs to copy the whole SqlDialectFactoryImpl > to make the custom changes. > This request is to make the default behavior in SqlDialectFactoryImpl > reusable so that extensions don't need to fork a whole class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4968) Calcite generates invalid MS SQL queries for the query with the LIMIT statement
[
https://issues.apache.org/jira/browse/CALCITE-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468146#comment-17468146
]
Julian Hyde commented on CALCITE-4968:
--
Since this case doesn't spell out the new/desired behavior, let me do it. After
the fix Calcite, for a query with fetch but no offset, generates a query using
{{TOP \(n)}}:
{code}
SELECT TOP (1)
FROM [foodmart].[employee]
{code}
If there is both fetch and offset, on MSSQL, Calcite now generates "OFFSET ...
FETCH":
{code}
SELECT *
FROM [foodmart].[employee]
OFFSET 1 ROWS
FETCH NEXT 1 ROWS ONLY
{code}
On Sybase, Calcite now generates "TOP ... START AT":
{code}
SELECT TOP (1) START AT 1
FROM foodmart.employee
{code}
> Calcite generates invalid MS SQL queries for the query with the LIMIT
> statement
> ---
>
> Key: CALCITE-4968
> URL: https://issues.apache.org/jira/browse/CALCITE-4968
> Project: Calcite
> Issue Type: Bug
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.30.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite converts the following query
> {code:sql}
> SELECT * FROM "employee" LIMIT 1
> {code}
> to the following one for {{MssqlSqlDialect}}:
> {code:sql}
> SELECT *
> FROM [foodmart].[employee]
> FETCH NEXT 1 ROWS ONLY
> {code}
> The issue is that MS SQL Server allows using {{FETCH}} (and {{OFFSET}})
> statements only when {{ORDER BY}} is specified, so the query above fails.
> One of the workarounds for this limitation is to insert {{ORDER BY (SELECT
> NULL)}} for the case when no actual {{ORDER BY}} statement is specified.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4968) Calcite generates invalid MS SQL queries for the query with the LIMIT statement
[
https://issues.apache.org/jira/browse/CALCITE-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468144#comment-17468144
]
Julian Hyde commented on CALCITE-4968:
--
Thanks for the PR, [~volodymyr] and [~cgivre]!
> Calcite generates invalid MS SQL queries for the query with the LIMIT
> statement
> ---
>
> Key: CALCITE-4968
> URL: https://issues.apache.org/jira/browse/CALCITE-4968
> Project: Calcite
> Issue Type: Bug
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.30.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite converts the following query
> {code:sql}
> SELECT * FROM "employee" LIMIT 1
> {code}
> to the following one for {{MssqlSqlDialect}}:
> {code:sql}
> SELECT *
> FROM [foodmart].[employee]
> FETCH NEXT 1 ROWS ONLY
> {code}
> The issue is that MS SQL Server allows using {{FETCH}} (and {{OFFSET}})
> statements only when {{ORDER BY}} is specified, so the query above fails.
> One of the workarounds for this limitation is to insert {{ORDER BY (SELECT
> NULL)}} for the case when no actual {{ORDER BY}} statement is specified.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4971) Update org.apache.httpcomponents:httpclient to latest
[ https://issues.apache.org/jira/browse/CALCITE-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468141#comment-17468141 ] Julian Hyde commented on CALCITE-4971: -- I see previous upgrades have called the components 'httpclient' (CALCITE-3180) and 'httpcore' (CALCITE-3104). Let's be consistent with those. FWIW the name of the project that maintains these components is 'Apache HttpComponents'. > Update org.apache.httpcomponents:httpclient to latest > -- > > Key: CALCITE-4971 > URL: https://issues.apache.org/jira/browse/CALCITE-4971 > Project: Calcite > Issue Type: Improvement > Components: avatica >Reporter: Istvan Toth >Priority: Major > > Apache commons httpclient/httpcomponent 4.5 depend on commons-logging and not > slf4j. This means that phoenix-thin requires explicit log4j configuration to > work. > We want all logging to go through SLF4j, and to be able to use any supported > backend. > Based on an an offline conversation with [~elserj] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4963) Extensibility of SqlDialectFactory lacks reusability of SqlDialectFactoryImpl.*
[ https://issues.apache.org/jira/browse/CALCITE-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468055#comment-17468055 ] Alessandro Solimando commented on CALCITE-4963: --- It's done [~marcobjorge] > Extensibility of SqlDialectFactory lacks reusability of > SqlDialectFactoryImpl.* > --- > > Key: CALCITE-4963 > URL: https://issues.apache.org/jira/browse/CALCITE-4963 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Marco Jorge >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > _(nicetities first - great project and thanks all for the great work)_ > Although it's possible to extend the SqlDialectFactory, the custom > implementation cannot reuse any of the behaviour of the default > SqlDialectFactoryImpl. The default SqlDialectFactoryImpl has lots of > important/reusable behaviour such as #getCasing, #isCaseSensitive, > #getNullCollation or even the default decisioning in the #create method. > If any user needs to provide a custom SqlDialect yet still support the > existing SqlDialects the user needs to copy the whole SqlDialectFactoryImpl > to make the custom changes. > This request is to make the default behavior in SqlDialectFactoryImpl > reusable so that extensions don't need to fork a whole class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4963) Extensibility of SqlDialectFactory lacks reusability of SqlDialectFactoryImpl.*
[ https://issues.apache.org/jira/browse/CALCITE-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468022#comment-17468022 ] Marco Jorge commented on CALCITE-4963: -- The PR seems to be blocked on workflows needing approval - can someone please help unblock? > Extensibility of SqlDialectFactory lacks reusability of > SqlDialectFactoryImpl.* > --- > > Key: CALCITE-4963 > URL: https://issues.apache.org/jira/browse/CALCITE-4963 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Marco Jorge >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > _(nicetities first - great project and thanks all for the great work)_ > Although it's possible to extend the SqlDialectFactory, the custom > implementation cannot reuse any of the behaviour of the default > SqlDialectFactoryImpl. The default SqlDialectFactoryImpl has lots of > important/reusable behaviour such as #getCasing, #isCaseSensitive, > #getNullCollation or even the default decisioning in the #create method. > If any user needs to provide a custom SqlDialect yet still support the > existing SqlDialects the user needs to copy the whole SqlDialectFactoryImpl > to make the custom changes. > This request is to make the default behavior in SqlDialectFactoryImpl > reusable so that extensions don't need to fork a whole class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4962) Protobuf debug does not show request/response type
[
https://issues.apache.org/jira/browse/CALCITE-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468020#comment-17468020
]
Marco Jorge commented on CALCITE-4962:
--
The PR seems to be approved - can someone please merge?
> Protobuf debug does not show request/response type
> --
>
> Key: CALCITE-4962
> URL: https://issues.apache.org/jira/browse/CALCITE-4962
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Marco Jorge
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> _(nicetities first - great project and thanks all for the great work)_
> The ProtobufTranslationImpl is able to debug the content of the messages
> encoded/decoded but it does not show the request/response type which is
> critical to identify abnormal situations.
> The current output is:
> {code:java}
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b" info { key:
> "password" value: "" } info { key: "user" value: "" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'metadata { server_address:
> "container-queryengine-tenant-be62-1792c303378a-677fcbfcc7-kvlz5:8080" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b" conn_props {
> is_dirty: true auto_commit: true has_auto_commit: true }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'conn_props { auto_commit: true has_auto_commit: true has_read_only:
> true } metadata { server_address:
> "container-queryengine-tenant-be62-1792c303378a-677fcbfcc7-kvlz5:8080" }'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:108 - Deserialized
> request 'connection_id: "ef7886f8-4800-4ddc-86c7-b01f6e7bd61b"'
> 2021-12-23 16:31:36 | TRACE | ProtobufTranslationImpl:351 - Serializing
> response 'props { key { name: "GET_NUMERIC_FUNCTIONS" } value { type: STRING
> string_value:
> "ABS,ACOS,ASIN,ATAN,ATAN2,CBRT,CEILING,COS,COT,DEGREES,EXP,FLOOR,LOG,LOG10,MOD,PI,POWER,RADIANS,RAND,ROUND,SIGN,SIN,SQRT,TAN,TRUNCATE"
> } } props { key { name: "GET_S_Q_L_KEYWORDS" } value { type: STRING
> string_value:
> "ABS,ALLOW,ARRAY,ARRAY_MAX_CARDINALITY,ASENSITIVE,ASYMMETRIC,ATOMIC,BEGIN_FRAME,BEGIN_PARTITION,BIGINT,BINARY,BLOB,BOOLEAN,CALLED,CARDINALITY,CEIL,CEILING,CLASSIFIER,CLOB,COLLECT,CORR,COVAR_POP,COVAR_SAMP,CUBE,CUME_DIST,CURRENT_CATALOG,CURRENT_DEFAULT_TRANSFORM_GROUP,CURRENT_ROLE,CURRENT_ROW,CURRENT_SCHEMA,CURRENT_TRANSFORM_GROUP_FOR_TYPE,CYCLE,DEFINE,DENSE_RANK,DEREF,DISALLOW,DYNAMIC,EACH,ELEMENT,EMPTY,END-EXEC,END_FRAME,END_PARTITION,EQUALS,EVERY,EXP,EXPLAIN,EXTEND,FILTER,FIRST_VALUE,FLOOR,FRAME_ROW,FREE,FUSION,GROUPING,GROUPS,HOLD,IMPORT,INITIAL,INTERSECTION,JSON_ARRAY,JSON_ARRAYAGG,JSON_EXISTS,JSON_OBJECT,JSON_OBJECTAGG,JSON_QUERY,JSON_VALUE,LAG,LARGE,LAST_VALUE,LATERAL,LEAD,LIKE_REGEX,LIMIT,LN,LOCALTIME,LOCALTIMESTAMP,MATCHES,MATCH_NUMBER,MATCH_RECOGNIZE,MEASURES,MEMBER,MERGE,METHOD,MINUS,MOD,MODIFIES,MULTISET,NCLOB,NEW,NONE,NORMALIZE,NTH_VALUE,NTILE,OCCURRENCES_REGEX,OFFSET,OLD,OMIT,ONE,OVER,OVERLAY,PARTITION,PATTERN,PER,PERCENT,PERCENTILE_CONT,PERCENTILE_DISC,PERCENT_RANK,PERIOD,PERMUTE,PORTION,POSITION_REGEX,POWER,PRECEDES,PREV,RANGE,RANK,READS,RECURSIVE,REF,REFERENCING,REGR_AVGX,REGR_AVGY,REGR_COUNT,REGR_INTERCEPT,REGR_R2,REGR_SLOPE,REGR_SXX,REGR_SXY,REGR_SYY,RELEASE,RESET,RESULT,ROLLUP,ROW,ROW_NUMBER,RUNNING,SAVEPOINT,SCOPE,SEARCH,SEEK,SENSITIVE,SHOW,SIMILAR,SKIP,SPECIFICTYPE,SQRT,START,STATIC,STDDEV_POP,STDDEV_SAMP,STREAM,SUBMULTISET,SUBSET,SUBSTRING_REGEX,SUCCEEDS,SYMMETRIC,SYSTEM,SYSTEM_TIME,TABLESAMPLE,TINYINT,TRANSLATE_REGEX,TREAT,TRIGGER,TRIM_ARRAY,TRUNCATE,UESCAPE,UNNEST,UPSERT,VALUE_OF,VARBINARY,VAR_POP,VAR_SAMP,VERSIONING,WIDTH_BUCKET,WINDOW,WITHIN,WITHOUT"
> } } props { key { name: "GET_DEFAULT_TRANSACTION_ISOLATION" } value { type:
> INTEGER } } props { key { name: "GET_TIME_DATE_FUNCTIONS" } value { type:
> STRING string_value:
> "CONVERT_TIMEZONE,CURDATE,CURTIME,DAYNAME,DAYOFMONTH,DAYOFWEEK,DAYOFYEAR,HOUR,MINUTE,MONTH,MONTHNAME,NOW,QUARTER,SECOND,TIMESTAMPADD,TIMESTAMPDIFF,TO_DATE,TO_TIMESTAMP,WEEK,YEAR"
> } } props { key { name: "GET_DRIVER_MAJOR_VERSION" } value { type: INTEGER
> number_value: 1 } } props { key { name: "GET_DRIVER_VERSION" } value { type:
> STRING string_value: "1.27.0" } } props { key { name:
> "GET_DATABASE_PRODUCT_VERSION" } value { type: STRING string_value: "1.27.0"
> } } props { key { name: "GET_SYSTEM_FUNCTIONS" } value { type: STRING
> string_value: "CONVERT,DATABASE,IFNULL,USER" } } props { key { name:
> "GET_STRING_FUNCTIONS" } value { type: STRING string_value:
>
