[jira] [Commented] (CALCITE-5060) SqlTypeUtil#canAssignFrom cover Map/Row/Multiset
[ https://issues.apache.org/jira/browse/CALCITE-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512199#comment-17512199 ] Julian Hyde commented on CALCITE-5060: -- SQL > SqlTypeUtil#canAssignFrom cover Map/Row/Multiset > > > Key: CALCITE-5060 > URL: https://issues.apache.org/jira/browse/CALCITE-5060 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Jianhui Dong >Priority: Major > Fix For: 1.31.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-5060) SqlTypeUtil#canAssignFrom cover Map/Row/Multiset
[
https://issues.apache.org/jira/browse/CALCITE-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511572#comment-17511572
]
Jianhui Dong edited comment on CALCITE-5060 at 3/25/22, 3:03 AM:
-
[~julianhyde]
{code:java}
@Test void testMapAssignment() {
final SqlTypeFactoryImpl typeFactory =
new SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
final RelDataType bigint = typeFactory.createSqlType(SqlTypeName.BIGINT);
final RelDataType bigintNullable =
typeFactory.createTypeWithNullability(bigint, true);
final RelDataType bigintNotNull =
typeFactory.createTypeWithNullability(bigint, false);
final RelDataType bigintNullableMap =
typeFactory.createMapType(bigintNullable, bigintNullable);
final RelDataType bigintMapNullable =
typeFactory.createTypeWithNullability(bigintNullableMap, true);
final RelDataType bigintNotnullMap =
typeFactory.createMapType(bigintNotNull, bigintNotNull);
assertThat(SqlTypeUtil.canAssignFrom(bigintNullableMap, bigintNotnullMap),
is(true));
assertThat(SqlTypeUtil.canAssignFrom(bigintNullableMap, bigintMapNullable),
is(true));
}
{code}
was (Author: lam167):
{code:java}
@Test void testMapAssignment() {
final SqlTypeFactoryImpl typeFactory =
new SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
final RelDataType bigint = typeFactory.createSqlType(SqlTypeName.BIGINT);
final RelDataType bigintNullable =
typeFactory.createTypeWithNullability(bigint, true);
final RelDataType bigintNotNull =
typeFactory.createTypeWithNullability(bigint, false);
final RelDataType bigintNullableMap =
typeFactory.createMapType(bigintNullable, bigintNullable);
final RelDataType bigintMapNullable =
typeFactory.createTypeWithNullability(bigintNullableMap, true);
final RelDataType bigintNotnullMap =
typeFactory.createMapType(bigintNotNull, bigintNotNull);
assertThat(SqlTypeUtil.canAssignFrom(bigintNullableMap, bigintNotnullMap),
is(true));
assertThat(SqlTypeUtil.canAssignFrom(bigintNullableMap, bigintMapNullable),
is(true));
}
{code}
> SqlTypeUtil#canAssignFrom cover Map/Row/Multiset
>
>
> Key: CALCITE-5060
> URL: https://issues.apache.org/jira/browse/CALCITE-5060
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jianhui Dong
>Priority: Major
> Fix For: 1.31.0
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-5044) JDBC adapter generates integer literal in ORDER BY, which some dialects wrongly interpret as a reference to a field
[
https://issues.apache.org/jira/browse/CALCITE-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5044.
--
Fix Version/s: 1.31.0
Resolution: Fixed
Fixed in
[a6a1e2ce|https://github.com/apache/calcite/commit/a6a1e2cef332893fd90286098869c56529e052c3];
thanks for the PR, [~wojustme]!
> JDBC adapter generates integer literal in ORDER BY, which some dialects
> wrongly interpret as a reference to a field
> ---
>
> Key: CALCITE-5044
> URL: https://issues.apache.org/jira/browse/CALCITE-5044
> Project: Calcite
> Issue Type: Improvement
>Reporter: Xurenhe
>Assignee: Xurenhe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Attachments: image-2022-03-17-21-45-22-988.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When there is a Sort RelNode that references an integer literal, the JDBC
> adapter converts this to a SQL ORDER BY clause that contains an integer
> literal as a sort key. Some dialects (most dialects, in fact) wrongly
> interpret as a reference to a field.
> There is ambiguous in the rel-to-sql's converter when meeting `order by
> constant `.
> Here is an example:
> {code:java}
> @Test void testOderByConstant() {
> final Function relFn = b -> b
> .scan("EMP")
> .project(b.literal(1), b.field(1), b.field(2))
> .sort(RelCollations.of(ImmutableList.of(
> new RelFieldCollation(0), new RelFieldCollation(1
> .project(b.field(2), b.field(1))
> .build();
> final String expected = "";
> relFn(relFn).ok(expected);
> } {code}
> Return sql:
> {code:java}
> SELECT "JOB", "ENAME"
> FROM "scott"."EMP"
> ORDER BY 1, "ENAME" {code}
> But, `ORDER BY 1` may mean 'sort by the first column in the select list'
> because of SqlConformance#isSortByOrdinal.
> I keep this the same semantics, by apply the rule of
> `CoreRules#SORT_REMOVE_CONSTANT_KEYS`
> Should the rel_to_sql's converter support it natively?
> *CODE:*
> https://github.com/wojustme/calcite/blob/6ad04e85875d9202e592a78cca8db807c5bde362/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1601
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5044) JDBC adapter generates integer literal in ORDER BY, which some dialects wrongly interpret as a reference to a field
[
https://issues.apache.org/jira/browse/CALCITE-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5044:
Labels: pull-request-available (was: )
> JDBC adapter generates integer literal in ORDER BY, which some dialects
> wrongly interpret as a reference to a field
> ---
>
> Key: CALCITE-5044
> URL: https://issues.apache.org/jira/browse/CALCITE-5044
> Project: Calcite
> Issue Type: Improvement
>Reporter: Xurenhe
>Assignee: Xurenhe
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2022-03-17-21-45-22-988.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When there is a Sort RelNode that references an integer literal, the JDBC
> adapter converts this to a SQL ORDER BY clause that contains an integer
> literal as a sort key. Some dialects (most dialects, in fact) wrongly
> interpret as a reference to a field.
> There is ambiguous in the rel-to-sql's converter when meeting `order by
> constant `.
> Here is an example:
> {code:java}
> @Test void testOderByConstant() {
> final Function relFn = b -> b
> .scan("EMP")
> .project(b.literal(1), b.field(1), b.field(2))
> .sort(RelCollations.of(ImmutableList.of(
> new RelFieldCollation(0), new RelFieldCollation(1
> .project(b.field(2), b.field(1))
> .build();
> final String expected = "";
> relFn(relFn).ok(expected);
> } {code}
> Return sql:
> {code:java}
> SELECT "JOB", "ENAME"
> FROM "scott"."EMP"
> ORDER BY 1, "ENAME" {code}
> But, `ORDER BY 1` may mean 'sort by the first column in the select list'
> because of SqlConformance#isSortByOrdinal.
> I keep this the same semantics, by apply the rule of
> `CoreRules#SORT_REMOVE_CONSTANT_KEYS`
> Should the rel_to_sql's converter support it natively?
> *CODE:*
> https://github.com/wojustme/calcite/blob/6ad04e85875d9202e592a78cca8db807c5bde362/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1601
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-5050) Metadata (RelMdRowCount) should reflect the fact that an Aggregate with no GROUP BY always returns 1 row
[
https://issues.apache.org/jira/browse/CALCITE-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5050.
--
Fix Version/s: 1.31.0
Resolution: Fixed
Fixed in
[1ce516dc|https://github.com/apache/calcite/commit/1ce516dcb660caa40ac806617f37cae9532bd0aa].
> Metadata (RelMdRowCount) should reflect the fact that an Aggregate with no
> GROUP BY always returns 1 row
>
>
> Key: CALCITE-5050
> URL: https://issues.apache.org/jira/browse/CALCITE-5050
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0, 1.30.0
>Reporter: Jing Zhang
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.31.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, RowCount of aggregate without group keys are unexpected.
> The problem could be appear in the following UT:
> {code:java}
> @Test void testRowCountAggregateEmptyKey1() {
> fixture()
> .withRelFn(b ->
> b.scan("EMP")
> .aggregate(
> b.groupKey(),
> b.count(false, "C"))
> .build())
> .assertThatRowCount(is(1D), is(1D), is(1D));
> }
> {code}
> Now, the above UT would be failed because row count return 1.4D instead of 1D.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5050) Metadata (RelMdRowCount) should reflect the fact that an Aggregate with no GROUP BY always returns 1 row
[
https://issues.apache.org/jira/browse/CALCITE-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5050:
-
Summary: Metadata (RelMdRowCount) should reflect the fact that an Aggregate
with no GROUP BY always returns 1 row (was: Aggregate with no GROUP BY always
returns 1 row)
> Metadata (RelMdRowCount) should reflect the fact that an Aggregate with no
> GROUP BY always returns 1 row
>
>
> Key: CALCITE-5050
> URL: https://issues.apache.org/jira/browse/CALCITE-5050
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0, 1.30.0
>Reporter: Jing Zhang
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently, RowCount of aggregate without group keys are unexpected.
> The problem could be appear in the following UT:
> {code:java}
> @Test void testRowCountAggregateEmptyKey1() {
> fixture()
> .withRelFn(b ->
> b.scan("EMP")
> .aggregate(
> b.groupKey(),
> b.count(false, "C"))
> .build())
> .assertThatRowCount(is(1D), is(1D), is(1D));
> }
> {code}
> Now, the above UT would be failed because row count return 1.4D instead of 1D.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-5064) Dialect factory returns ANSI SQL dialect for BigQuery
[ https://issues.apache.org/jira/browse/CALCITE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512146#comment-17512146 ] Vova Vysotskyi commented on CALCITE-5064: - Thanks for letting me know about the bqjdbc! It is placed in maven central so should be more convenient to use. I've added that database product name also. > Dialect factory returns ANSI SQL dialect for BigQuery > - > > Key: CALCITE-5064 > URL: https://issues.apache.org/jira/browse/CALCITE-5064 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Affects Versions: 1.30.0 >Reporter: Vova Vysotskyi >Assignee: Vova Vysotskyi >Priority: Major > > `SqlDialectFactoryImpl.create` returns `AnsiSqlDialect` for the case of > BigQuery instead of `BigQuerySqlDialect`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-5064) Dialect factory returns ANSI SQL dialect for BigQuery
[ https://issues.apache.org/jira/browse/CALCITE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512122#comment-17512122 ] Julian Hyde commented on CALCITE-5064: -- The other commonly used driver is [bqjdbc|https://github.com/looker-open-source/bqjdbc]. I [see that it returns|https://github.com/looker-open-source/bqjdbc/blob/1ee44c6c57746cd3c6be5e376a165f2c2165b683/src/main/java/net/starschema/clouddb/jdbc/BQDatabaseMetadata.java#L694] databaseProductName "Google Big Query". I would appreciate if recognize that product name, so there's a chance that your fix will work for bqjdbc also. > Dialect factory returns ANSI SQL dialect for BigQuery > - > > Key: CALCITE-5064 > URL: https://issues.apache.org/jira/browse/CALCITE-5064 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Affects Versions: 1.30.0 >Reporter: Vova Vysotskyi >Assignee: Vova Vysotskyi >Priority: Major > > `SqlDialectFactoryImpl.create` returns `AnsiSqlDialect` for the case of > BigQuery instead of `BigQuerySqlDialect`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-5064) Dialect factory returns ANSI SQL dialect for BigQuery
[ https://issues.apache.org/jira/browse/CALCITE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512115#comment-17512115 ] Vova Vysotskyi commented on CALCITE-5064: - Hi [~julianhyde], I was using the Simba JDBC Driver (downloaded from [here|https://cloud.google.com/bigquery/docs/reference/odbc-jdbc-drivers#jdbc_release_12221026]), but didn't have a chance to take a look at other driver implementations. > Dialect factory returns ANSI SQL dialect for BigQuery > - > > Key: CALCITE-5064 > URL: https://issues.apache.org/jira/browse/CALCITE-5064 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Affects Versions: 1.30.0 >Reporter: Vova Vysotskyi >Assignee: Vova Vysotskyi >Priority: Major > > `SqlDialectFactoryImpl.create` returns `AnsiSqlDialect` for the case of > BigQuery instead of `BigQuerySqlDialect`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CALCITE-5064) Dialect factory returns ANSI SQL dialect for BigQuery
[ https://issues.apache.org/jira/browse/CALCITE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde updated CALCITE-5064: - Component/s: jdbc-adapter > Dialect factory returns ANSI SQL dialect for BigQuery > - > > Key: CALCITE-5064 > URL: https://issues.apache.org/jira/browse/CALCITE-5064 > Project: Calcite > Issue Type: Bug > Components: jdbc-adapter >Affects Versions: 1.30.0 >Reporter: Vova Vysotskyi >Assignee: Vova Vysotskyi >Priority: Major > > `SqlDialectFactoryImpl.create` returns `AnsiSqlDialect` for the case of > BigQuery instead of `BigQuerySqlDialect`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-5064) Dialect factory returns ANSI SQL dialect for BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512111#comment-17512111
]
Julian Hyde commented on CALCITE-5064:
--
Ah yes, I see that CALCITE-2623 added support for BigQuery in
{{SqlDialectFactoryImpl.simple}} but not in {{SqlDialectFactoryImpl.create}}.
Just curious, what JDBC driver are you using for BigQuery? I know there are
several, and I wonder they they all return the same value for
{{databaseProductName}}.
> Dialect factory returns ANSI SQL dialect for BigQuery
> -
>
> Key: CALCITE-5064
> URL: https://issues.apache.org/jira/browse/CALCITE-5064
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.30.0
>Reporter: Vova Vysotskyi
>Assignee: Vova Vysotskyi
>Priority: Major
>
> `SqlDialectFactoryImpl.create` returns `AnsiSqlDialect` for the case of
> BigQuery instead of `BigQuerySqlDialect`.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (CALCITE-5064) Dialect factory returns ANSI SQL dialect for BigQuery
Vova Vysotskyi created CALCITE-5064: --- Summary: Dialect factory returns ANSI SQL dialect for BigQuery Key: CALCITE-5064 URL: https://issues.apache.org/jira/browse/CALCITE-5064 Project: Calcite Issue Type: Bug Affects Versions: 1.30.0 Reporter: Vova Vysotskyi Assignee: Vova Vysotskyi `SqlDialectFactoryImpl.create` returns `AnsiSqlDialect` for the case of BigQuery instead of `BigQuerySqlDialect`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-5044) JDBC adapter generates integer literal in ORDER BY, which some dialects wrongly interpret as a reference to a field
[
https://issues.apache.org/jira/browse/CALCITE-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511586#comment-17511586
]
Xurenhe edited comment on CALCITE-5044 at 3/24/22, 11:59 AM:
-
Hi [~julianhyde]
I have finished the review.
I think we need one test case: numeric constant with direction info in the
order-by.
I have integrated more cases into one test method.
Code is updated in my branch:
[https://github.com/wojustme/calcite/commit/22d3b6c845152dd5270bad9974d7fa505e63dfe6|https://github.com/wojustme/calcite/commit/22d3b6c845152dd5270bad9974d7fa505e63dfe6.]
please take a time to review it. Thanks.
was (Author: wojustme):
Hi [~julianhyde]
I have finished the review.
I think we need one test case: numeric constant with direction info in the
order-by.
I have integrated more cases into one test method.
Code is updated in my branch:
[https://github.com/wojustme/calcite/commit/22d3b6c845152dd5270bad9974d7fa505e63dfe6.]
please take a time to review it. Thanks.
> JDBC adapter generates integer literal in ORDER BY, which some dialects
> wrongly interpret as a reference to a field
> ---
>
> Key: CALCITE-5044
> URL: https://issues.apache.org/jira/browse/CALCITE-5044
> Project: Calcite
> Issue Type: Improvement
>Reporter: Xurenhe
>Assignee: Xurenhe
>Priority: Major
> Attachments: image-2022-03-17-21-45-22-988.png
>
>
> When there is a Sort RelNode that references an integer literal, the JDBC
> adapter converts this to a SQL ORDER BY clause that contains an integer
> literal as a sort key. Some dialects (most dialects, in fact) wrongly
> interpret as a reference to a field.
> There is ambiguous in the rel-to-sql's converter when meeting `order by
> constant `.
> Here is an example:
> {code:java}
> @Test void testOderByConstant() {
> final Function relFn = b -> b
> .scan("EMP")
> .project(b.literal(1), b.field(1), b.field(2))
> .sort(RelCollations.of(ImmutableList.of(
> new RelFieldCollation(0), new RelFieldCollation(1
> .project(b.field(2), b.field(1))
> .build();
> final String expected = "";
> relFn(relFn).ok(expected);
> } {code}
> Return sql:
> {code:java}
> SELECT "JOB", "ENAME"
> FROM "scott"."EMP"
> ORDER BY 1, "ENAME" {code}
> But, `ORDER BY 1` may mean 'sort by the first column in the select list'
> because of SqlConformance#isSortByOrdinal.
> I keep this the same semantics, by apply the rule of
> `CoreRules#SORT_REMOVE_CONSTANT_KEYS`
> Should the rel_to_sql's converter support it natively?
> *CODE:*
> https://github.com/wojustme/calcite/blob/6ad04e85875d9202e592a78cca8db807c5bde362/core/src/test/java/org/apache/calcite/rel/rel2sql/RelToSqlConverterTest.java#L1601
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4989) Nested JSON_OBJECT creation does not produce proper json
[
https://issues.apache.org/jira/browse/CALCITE-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511725#comment-17511725
]
Stamatis Zampetakis commented on CALCITE-4989:
--
[~libenchao] I agree with your analysis. I think point 2 can be handled as part
of this JIRA, possibly point 1 as well if not too complex. For point 3, it
would be good to have a separate JIRA.
> Nested JSON_OBJECT creation does not produce proper json
>
>
> Key: CALCITE-4989
> URL: https://issues.apache.org/jira/browse/CALCITE-4989
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.29.0
>Reporter: Mans Singh
>Priority: Critical
> Labels: json_object, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I am trying to create a nested json object using JSON_OBJECT and am getting a
> json with escaped quotes.
>
> I have the following query in sql line :
>
> {code:java}
> select JSON_OBJECT(
> KEY 'level1'
> VALUE(
> JSON_OBJECT(
> KEY 'level2'
> VALUE(
> JSON_OBJECT(
> KEY 'level3'
> VALUE 'val3')
> )
> )
> )
> )
> from (values ('{"a":{"b":2}}')) t(v);
>
> {code}
> And it produces the result:
>
> {noformat}
> -
> EXPR$0
> -
> {"level1":" {\"level2\":\"{\\\"level3\\\":\\\"val3\\\"}\"}"}
> -
> {noformat}
>
> I was expecting the result as follows (without quote escapes):
>
> {noformat}
> {"level1":{"level2":{"level3":"val3"}}}
>
> {noformat}
> Also, see examples created by Stamatis
> -
> [https://github.com/zabetak/calcite/commit/988c13ce1ff551d6e4046a3c027ff298f79971f8]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511719#comment-17511719
]
Istvan Toth commented on CALCITE-5009:
--
I've been mulling over this.
In the strictest sense, transparent reconnecting always breaks JDBC semantics,
as we have no idea of how the user changed the state of the connection, nor is
it possible for us to know that.
For example, even for the simplest non-transactional select statement, the user
may have set a locale on the connections via a "SET locale=x" SQL command, and
the new connection would have the default locale instead, delivering unexpected
results.
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
> Currently, if the server-side JDBC connection goes away for any reason
> * Avatica connection cache expiry
> * LB/HA Failover
> * Some problem with the "real" connection
> we attempt to create a new "real" JDBC connection, and continue using that
> instead of the original connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss
[
https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth reassigned CALCITE-5009:
Assignee: Istvan Toth
> Transparent JDBC connection re-creation may lead to data loss
> -
>
> Key: CALCITE-5009
> URL: https://issues.apache.org/jira/browse/CALCITE-5009
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
> Currently, if the server-side JDBC connection goes away for any reason
> * Avatica connection cache expiry
> * LB/HA Failover
> * Some problem with the "real" connection
> we attempt to create a new "real" JDBC connection, and continue using that
> instead of the original connection
> [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796]
> This is fine for most read-only connections, but it can break transaction
> semantics, which is captured in the "real" connection object.
> {noformat}
> conn.setAutocommit(false)
> stmt = conn.createStatement()
> execute(insert A)
> //Connection lost and object recreated which now proxies a new "real"
> connection
> execute(insert B)
> conn.commit()
> //We have lost "insert A"{noformat}
> I'm not sure if we synchronize autocommit state of the new connection to the
> lost one or not, but it's bad either way.
>
> We should either completely drop this feature, add some logic that avoids it
> if there is an open transaction and/or only allow it for connections that
> have the readOnly flag set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-5053) Implement “show catalogs/databases/tables" semantics
[ https://issues.apache.org/jira/browse/CALCITE-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] itxiangkui updated CALCITE-5053: Summary: Implement “show catalogs/databases/tables" semantics (was: Implement “show catalogs/databases/schemas" semantics) > Implement “show catalogs/databases/tables" semantics > -- > > Key: CALCITE-5053 > URL: https://issues.apache.org/jira/browse/CALCITE-5053 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.29.0 >Reporter: itxiangkui >Priority: Major > > our data warehouse has integrate es/mysql/druid and so on ,also the dba > manage the database difficultly。 > the default sql has implement the "DESCRIBE CATALOG/SCHEMA" and so on > but most of dba may prefer a simple sql grammar like "show databases" ... -- This message was sent by Atlassian Jira (v8.20.1#820001)
