[jira] [Updated] (IGNITE-21676) Sql. Move system view definitions to a separate package of a catalog module
[ https://issues.apache.org/jira/browse/IGNITE-21676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21676: -- Fix Version/s: 3.0.0-beta2 > Sql. Move system view definitions to a separate package of a catalog module > --- > > Key: IGNITE-21676 > URL: https://issues.apache.org/jira/browse/IGNITE-21676 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Let's move code related to system view definitions to a separate package, so > CatalogManagerImpl > only contains an implementation of SystemViewProvider interface/or a list of > a "imports" of system view definitions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21676) Sql. Move system view definitions to a separate package of a catalog module
[ https://issues.apache.org/jira/browse/IGNITE-21676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-21676: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Move system view definitions to a separate package of a catalog module > --- > > Key: IGNITE-21676 > URL: https://issues.apache.org/jira/browse/IGNITE-21676 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Let's move code related to system view definitions to a separate package, so > CatalogManagerImpl > only contains an implementation of SystemViewProvider interface/or a list of > a "imports" of system view definitions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22148) BinaryTupleFormatException for UUID
[
https://issues.apache.org/jira/browse/IGNITE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22148:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> BinaryTupleFormatException for UUID
> ---
>
> Key: IGNITE-22148
> URL: https://issues.apache.org/jira/browse/IGNITE-22148
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Simple example to reproduce the issue:
> {code:java}
> sql("create table tdd(a uuid default gen_random_uuid, b int, primary key (a)
> )");
> sql("insert into tdd(b) values(22)");{code}
> we got
> {code:java}
> Caused by: org.apache.ignite.internal.binarytuple.BinaryTupleFormatException:
> IGN-CMN-65535 TraceId:5dfdd34c-6722-41ad-85f3-13aa0c483454 Invalid length for
> a tuple element: 36
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleParser.uuidValue(BinaryTupleParser.java:377)
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleReader.uuidValue(BinaryTupleReader.java:305)
> at
> org.apache.ignite.internal.sql.engine.util.Commons.readValue(Commons.java:487)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlOutputBinaryRow.newRow(SqlOutputBinaryRow.java:85)
> at
> org.apache.ignite.internal.sql.engine.exec.TableRowConverterImpl.toBinaryRow(TableRowConverterImpl.java:83)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insert(UpdatableTableImpl.java:187)
> at
> org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$1(KeyValueModifyPlan.java:133)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
> {code}
> Let's add validation for `create table` at least for defaults
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22148) BinaryTupleFormatException for UUID
[
https://issues.apache.org/jira/browse/IGNITE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22148:
--
Fix Version/s: 3.0.0-beta2
> BinaryTupleFormatException for UUID
> ---
>
> Key: IGNITE-22148
> URL: https://issues.apache.org/jira/browse/IGNITE-22148
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Simple example to reproduce the issue:
> {code:java}
> sql("create table tdd(a uuid default gen_random_uuid, b int, primary key (a)
> )");
> sql("insert into tdd(b) values(22)");{code}
> we got
> {code:java}
> Caused by: org.apache.ignite.internal.binarytuple.BinaryTupleFormatException:
> IGN-CMN-65535 TraceId:5dfdd34c-6722-41ad-85f3-13aa0c483454 Invalid length for
> a tuple element: 36
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleParser.uuidValue(BinaryTupleParser.java:377)
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleReader.uuidValue(BinaryTupleReader.java:305)
> at
> org.apache.ignite.internal.sql.engine.util.Commons.readValue(Commons.java:487)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlOutputBinaryRow.newRow(SqlOutputBinaryRow.java:85)
> at
> org.apache.ignite.internal.sql.engine.exec.TableRowConverterImpl.toBinaryRow(TableRowConverterImpl.java:83)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insert(UpdatableTableImpl.java:187)
> at
> org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$1(KeyValueModifyPlan.java:133)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
> {code}
> Let's add validation for `create table` at least for defaults
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22164) Sql. Merge throws exception if columns defined in different from table definition order.
[
https://issues.apache.org/jira/browse/IGNITE-22164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22164:
--
Fix Version/s: 3.0.0-beta2
> Sql. Merge throws exception if columns defined in different from table
> definition order.
>
>
> Key: IGNITE-22164
> URL: https://issues.apache.org/jira/browse/IGNITE-22164
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Reproducer:
> {noformat}
> sql("create table limitedChar (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> sql("create table test1 (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> String mergeSql2 = "MERGE INTO limitedChar dst USING test1 src ON
> dst.pk = src.pk "
> + "WHEN MATCHED THEN UPDATE SET f1 = '12' "
> + "WHEN NOT MATCHED THEN INSERT (pk, f2, f1) VALUES (src.pk,
> src.f2, src.f1)";
> sql(mergeSql2);
> {noformat}
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.sql.engine.rel.logical.IgniteLogicalTableScan
> cannot be cast to class org.apache.calcite.rel.logical.LogicalProject
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22061:
-
Assignee: Pavel Pereslegin
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the
> pre-allocated buffer to be significantly larger than required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19103) Sql. Change implicit primary key column's type to UUID.
[ https://issues.apache.org/jira/browse/IGNITE-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19103: -- Labels: ignite-3 (was: calcite3-required ignite-3) > Sql. Change implicit primary key column's type to UUID. > --- > > Key: IGNITE-19103 > URL: https://issues.apache.org/jira/browse/IGNITE-19103 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Change implicit primary key column's type to UUID. Replace calls to > gen_random_uuid with calls to rand_uuid,`gen_random_uuid` function should be > removed. > As a part of this ticket update SQL grammar to make it possible to specify > function calls (without arguments) in for DEFAULT column values. Because at > the moment it looks like some functions that have no arguments can be called > with omitted parentheses and that is not the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19103) Sql. Change implicit primary key column's type to UUID.
[ https://issues.apache.org/jira/browse/IGNITE-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19103: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Change implicit primary key column's type to UUID. > --- > > Key: IGNITE-19103 > URL: https://issues.apache.org/jira/browse/IGNITE-19103 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Change implicit primary key column's type to UUID. Replace calls to > gen_random_uuid with calls to rand_uuid,`gen_random_uuid` function should be > removed. > As a part of this ticket update SQL grammar to make it possible to specify > function calls (without arguments) in for DEFAULT column values. Because at > the moment it looks like some functions that have no arguments can be called > with omitted parentheses and that is not the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19103) Sql. Change implicit primary key column's type to UUID.
[ https://issues.apache.org/jira/browse/IGNITE-19103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-19103: -- Fix Version/s: 3.0.0-beta2 > Sql. Change implicit primary key column's type to UUID. > --- > > Key: IGNITE-19103 > URL: https://issues.apache.org/jira/browse/IGNITE-19103 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta2 >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: calcite3-required, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Change implicit primary key column's type to UUID. Replace calls to > gen_random_uuid with calls to rand_uuid,`gen_random_uuid` function should be > removed. > As a part of this ticket update SQL grammar to make it possible to specify > function calls (without arguments) in for DEFAULT column values. Because at > the moment it looks like some functions that have no arguments can be called > with omitted parentheses and that is not the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22301) Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
Pavel Pereslegin created IGNITE-22301:
-
Summary: Test CatalogManagerSelfTest.alwaysWaitForActivationTime
is flaky
Key: IGNITE-22301
URL: https://issues.apache.org/jira/browse/IGNITE-22301
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
>From time to time the CatalogManagerSelfTest.alwaysWaitForActivationTime test
>fails with the following error ([test
>history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-3345017748753084393=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50]).
{noformat}
org.mockito.exceptions.verification.TooManyActualInvocations:
testCommand.get();
Wanted 2 times:
-> at
org.apache.ignite.internal.catalog.CatalogManagerSelfTest$TestCommand.get(CatalogManagerSelfTest.java:472)
But was 3 times:
-> at
org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
-> at
org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
-> at
org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
{noformat}
This failure reproduces locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22301) Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22301:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Test CatalogManagerSelfTest.alwaysWaitForActivationTime is flaky
>
>
> Key: IGNITE-22301
> URL: https://issues.apache.org/jira/browse/IGNITE-22301
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> From time to time the CatalogManagerSelfTest.alwaysWaitForActivationTime test
> fails with the following error ([test
> history|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual==testDetails=-3345017748753084393=TEST_STATUS_DESC_ApacheIgnite3xGradle_Test_RunUnitTests_virtual=__all_branches__=50]).
> {noformat}
> org.mockito.exceptions.verification.TooManyActualInvocations:
> testCommand.get();
> Wanted 2 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerSelfTest$TestCommand.get(CatalogManagerSelfTest.java:472)
> But was 3 times:
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> -> at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.saveUpdate(CatalogManagerImpl.java:491)
> {noformat}
> This failure reproduces locally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21872) Implement IgniteSql#executeBatchAsync() accepting Statement
[ https://issues.apache.org/jira/browse/IGNITE-21872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-21872: - Assignee: Pavel Pereslegin > Implement IgniteSql#executeBatchAsync() accepting Statement > --- > > Key: IGNITE-21872 > URL: https://issues.apache.org/jira/browse/IGNITE-21872 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Roman Puchkovskiy >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > The method is not implemented now, it just throws > UnsupportedOperationException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22293) Sql. SqlToRelConverter fails to convert SqlMerge AST to relational expression
Pavel Pereslegin created IGNITE-22293:
-
Summary: Sql. SqlToRelConverter fails to convert SqlMerge AST to
relational expression
Key: IGNITE-22293
URL: https://issues.apache.org/jira/browse/IGNITE-22293
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
This is a clone of CALCITE-6412 issue.
By default {{SqlToRelConverter}} is not able to convert AST with SqlMerge that
contains all columns but in an order different from the order specified by the
schema (see IGNITE-22164).
The workaround for this issue n the AI3 codebase should be removed when this
bug is fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22293) Sql. SqlToRelConverter fails to convert SqlMerge AST to relational expression
[
https://issues.apache.org/jira/browse/IGNITE-22293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22293:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. SqlToRelConverter fails to convert SqlMerge AST to relational expression
> -
>
> Key: IGNITE-22293
> URL: https://issues.apache.org/jira/browse/IGNITE-22293
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Minor
> Labels: ignite-3
>
> This is a clone of CALCITE-6412 issue.
> By default {{SqlToRelConverter}} is not able to convert AST with SqlMerge
> that contains all columns but in an order different from the order specified
> by the schema (see IGNITE-22164).
> The workaround for this issue n the AI3 codebase should be removed when this
> bug is fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22164) Sql. Merge throws exception if columns defined in different from table definition order.
[
https://issues.apache.org/jira/browse/IGNITE-22164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22164:
-
Assignee: Pavel Pereslegin
> Sql. Merge throws exception if columns defined in different from table
> definition order.
>
>
> Key: IGNITE-22164
> URL: https://issues.apache.org/jira/browse/IGNITE-22164
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Reproducer:
> {noformat}
> sql("create table limitedChar (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> sql("create table test1 (pk int primary key, f1 CHAR(2), f2
> CHAR(2))");
> String mergeSql2 = "MERGE INTO limitedChar dst USING test1 src ON
> dst.pk = src.pk "
> + "WHEN MATCHED THEN UPDATE SET f1 = '12' "
> + "WHEN NOT MATCHED THEN INSERT (pk, f2, f1) VALUES (src.pk,
> src.f2, src.f1)";
> sql(mergeSql2);
> {noformat}
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.sql.engine.rel.logical.IgniteLogicalTableScan
> cannot be cast to class org.apache.calcite.rel.logical.LogicalProject
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844600#comment-17844600
]
Pavel Pereslegin edited comment on IGNITE-22061 at 5/15/24 9:04 AM:
The easiest way is to use {{stripTrailingZeros}} (similar to what is done in
{{BinaryTupleBuilder#appendDecimalNotNull}}), but perhaps be we can come up
with a more efficient estimation (or at least not call {{stripTrailingZeros}}
twice).
was (Author: xtern):
The easiest way is to use {{stripTrailingZeros}} (similar to what is done in
{{BinaryTupleBuilder#appendDecimalNotNull}}), but perhaps be we can come up
with a more efficient estimation.
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the
> pre-allocated buffer to be significantly larger than required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22000) Sql. Get rid of unnecessary conversion of DDL commands
[
https://issues.apache.org/jira/browse/IGNITE-22000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22000:
--
Fix Version/s: 3.0.0-beta2
> Sql. Get rid of unnecessary conversion of DDL commands
> --
>
> Key: IGNITE-22000
> URL: https://issues.apache.org/jira/browse/IGNITE-22000
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, refactoring
> Fix For: 3.0.0-beta2
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Every DDL command goes through two levels of conversion now.
> From {{AST}} into {{DdlCommand}} using {{DdlSqlToCommandConverter}}.
> And from {{DdlCommand}} into {{CatalogCommand}} (using
> {{DdlToCatalogCommandConverter}}).
> It looks like we should do only single conversion {{AST}} =>
> {{CatalogCommand}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21167) Sql. Change exception message raised while calling transactions with disabled autoCommit from jdbc
[
https://issues.apache.org/jira/browse/IGNITE-21167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21167:
--
Fix Version/s: 3.0.0-beta2
> Sql. Change exception message raised while calling transactions with disabled
> autoCommit from jdbc
> --
>
> Key: IGNITE-21167
> URL: https://issues.apache.org/jira/browse/IGNITE-21167
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> After ignite-20661 was implemented, statements like:
> {code:java}
> "START TRANSACTION; SELECT 1; COMMIT;"
> {code}
> will throw non friendly exception like :
> "Transaction control statement cannot be executed within an external
> transaction"
> Need to be changed.
> Discussed in [1]
> [1] https://github.com/apache/ignite-3/pull/2906#discussion_r1420178983
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22197) Move DDL 'IF EXISTS` flag handling inside the catalog command
[
https://issues.apache.org/jira/browse/IGNITE-22197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22197:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Move DDL 'IF EXISTS` flag handling inside the catalog command
> -
>
> Key: IGNITE-22197
> URL: https://issues.apache.org/jira/browse/IGNITE-22197
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT
> EXISTS' flags. We handle the exception thrown by the command and set the
> result to false if the flag was set. And this result (true/false) can be
> obtained by the user using {{AsyncResultSet#wasApplied}} method.
> With the current approach, a problem may arise when processing a batch
> command.
> For example
> {code:sql}
> CREATE TABLE IF NOT EXISTS Person... -- command 1
> CREATE TABLE IF NOT EXISTS City... -- command 2
> {code}
> If the Person table exists, the batch will not be fully executed.
> To address this we can move flag handling inside the command itself.
> To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}}
> so that it returns not only the catalog version, but also a flag indicating
> that something was changed when this command was executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22197) Move DDL 'IF EXISTS` flag handling inside the catalog command
Pavel Pereslegin created IGNITE-22197:
-
Summary: Move DDL 'IF EXISTS` flag handling inside the catalog
command
Key: IGNITE-22197
URL: https://issues.apache.org/jira/browse/IGNITE-22197
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Pavel Pereslegin
Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT
EXISTS' flags. We handle the exception thrown by the command and set the result
to false if the flag was set. And this result (true/false) can be obtained by
the user using {{AsyncResultSet#wasApplied}} method.
With the current approach, a problem may arise when processing a batch command.
For example
{code:sql}
CREATE TABLE IF NOT EXISTS Person... -- command 1
CREATE TABLE IF NOT EXISTS City...-- command 2
{code}
If the Person table exists, the batch will not be fully executed.
To address this we can move flag handling inside the command itself.
To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} so
that it returns not only the catalog version, but also a flag indicating that
something was changed when this command was executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22197) Move DDL 'IF EXISTS` flag handling inside the catalog command
[
https://issues.apache.org/jira/browse/IGNITE-22197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22197:
--
Description:
Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT
EXISTS' flags. We handle the exception thrown by the command and set the result
to false if the flag was set. And this result (true/false) can be obtained by
the user using {{AsyncResultSet#wasApplied}} method.
With the current approach, a problem may arise when processing a batch command.
For example
{code:sql}
CREATE TABLE IF NOT EXISTS Person... -- command 1
CREATE TABLE IF NOT EXISTS City... -- command 2
{code}
If the Person table exists, the batch will not be fully executed.
To address this we can move flag handling inside the command itself.
To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} so
that it returns not only the catalog version, but also a flag indicating that
something was changed when this command was executed.
was:
Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT
EXISTS' flags. We handle the exception thrown by the command and set the result
to false if the flag was set. And this result (true/false) can be obtained by
the user using {{AsyncResultSet#wasApplied}} method.
With the current approach, a problem may arise when processing a batch command.
For example
{code:sql}
CREATE TABLE IF NOT EXISTS Person... -- command 1
CREATE TABLE IF NOT EXISTS City...-- command 2
{code}
If the Person table exists, the batch will not be fully executed.
To address this we can move flag handling inside the command itself.
To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}} so
that it returns not only the catalog version, but also a flag indicating that
something was changed when this command was executed.
> Move DDL 'IF EXISTS` flag handling inside the catalog command
> -
>
> Key: IGNITE-22197
> URL: https://issues.apache.org/jira/browse/IGNITE-22197
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently, the catalog command itself does not handle the 'IF EXISTS' 'IF NOT
> EXISTS' flags. We handle the exception thrown by the command and set the
> result to false if the flag was set. And this result (true/false) can be
> obtained by the user using {{AsyncResultSet#wasApplied}} method.
> With the current approach, a problem may arise when processing a batch
> command.
> For example
> {code:sql}
> CREATE TABLE IF NOT EXISTS Person... -- command 1
> CREATE TABLE IF NOT EXISTS City... -- command 2
> {code}
> If the Person table exists, the batch will not be fully executed.
> To address this we can move flag handling inside the command itself.
> To keep "wasApplied" working, we can rework a bit {{CatalogManager#execute}}
> so that it returns not only the catalog version, but also a flag indicating
> that something was changed when this command was executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844600#comment-17844600
]
Pavel Pereslegin commented on IGNITE-22061:
---
The easiest way is to use {{stripTrailingZeros}} (similar to what is done in
{{BinaryTupleBuilder#appendDecimalNotNull}}), but perhaps be we can come up
with a more efficient estimation.
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the
> pre-allocated buffer to be significantly larger than required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22061:
--
Description:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
*UPDATE*
Binary tuple stores bigdecimal in compact form after IGNITE-21745.
This issue is about pre-allocation buffer for binary tuple.
Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
It estimates the size bigdecimal, including trailing zeros, causing the
pre-allocated buffer to be significantly larger than required.
was:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size bigdecimal, including trailing zeros, causing the
> pre-allocated buffer to be significantly larger than required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22061:
--
Description:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
*UPDATE*
Binary tuple stores bigdecimal in compact form after IGNITE-21745.
This issue is about pre-allocation buffer for binary tuple.
Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
It estimates the size of BigDecimal, including trailing zeros, causing the
pre-allocated buffer to be significantly larger than required.
was:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
*UPDATE*
Binary tuple stores bigdecimal in compact form after IGNITE-21745.
This issue is about pre-allocation buffer for binary tuple.
Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
It estimates the size bigdecimal, including trailing zeros, causing the
pre-allocated buffer to be significantly larger than required.
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> Binary tuple stores bigdecimal in compact form after IGNITE-21745.
> This issue is about pre-allocation buffer for binary tuple.
> Look at the {{TupleMarshallerImpl#gatherStatistics}} for example.
> It estimates the size of BigDecimal, including trailing zeros, causing the
> pre-allocated buffer to be significantly larger than required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22061:
--
Description:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
was:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
*UPDATE*
The
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[ https://issues.apache.org/jira/browse/IGNITE-22061 ]
Pavel Pereslegin deleted comment on IGNITE-22061:
---
was (Author: xtern):
Looks like this issue is fixed in IGNITE-21745
The following test case now passes successfully.
{code:java}
int scale = Short.MAX_VALUE;
BigDecimal value = new BigDecimal("10").setScale(scale, RoundingMode.HALF_UP);
ByteBuffer bytes = new BinaryTupleBuilder(1).appendDecimal(value,
scale).build();
assertEquals(5, bytes.limit());
{code}
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22061:
--
Description:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
*UPDATE*
The
was:
BigDecimals that represent integer numbers can take up a lot of space, when
scale is specified:
{code:java}
BigDecimal dc = new BigDecimal("").setScale(1024, RoundingMode.HALF_UP);
System.out.println("Difference:");
System.out.println(MarshallerUtil.sizeInBytes(dc) -
dc.stripTrailingZeros().setScale(0,
RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
{code}
The code prints:
{code}
Difference:
427
{code}
Let's update BinaryTuple format to store such numbers in more compact form that
does not store trailing zeros.
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
> *UPDATE*
> The
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22061:
-
Assignee: (was: Pavel Pereslegin)
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844321#comment-17844321
]
Pavel Pereslegin edited comment on IGNITE-22061 at 5/7/24 2:34 PM:
---
Looks like this issue is fixed in IGNITE-21745
The following test case now passes successfully.
{code:java}
int scale = Short.MAX_VALUE;
BigDecimal value = new BigDecimal("10").setScale(scale, RoundingMode.HALF_UP);
ByteBuffer bytes = new BinaryTupleBuilder(1).appendDecimal(value,
scale).build();
assertEquals(5, bytes.limit());
{code}
was (Author: xtern):
Looks like this issue is fixed in IGNITE-21745
The following test case now passes successfully.
{code:java}
BigDecimal value = new BigDecimal("10").setScale(Short.MAX_VALUE,
RoundingMode.HALF_UP);
ByteBuffer bytes = new BinaryTupleBuilder(1).appendDecimal(value,
Short.MAX_VALUE).build();
assertEquals(5, bytes.limit());
{code}
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844321#comment-17844321
]
Pavel Pereslegin commented on IGNITE-22061:
---
Looks like this issue is fixed in IGNITE-21745
The following test case now passes successfully.
{code:java}
BigDecimal value = new BigDecimal("10").setScale(Short.MAX_VALUE,
RoundingMode.HALF_UP);
ByteBuffer bytes = new BinaryTupleBuilder(1).appendDecimal(value,
Short.MAX_VALUE).build();
assertEquals(5, bytes.limit());
{code}
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22061:
--
Component/s: (was: sql)
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22061:
--
Component/s: sql
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22061) Use compact representation of BigDecimal with large scale for integers / numbers with trailing zeros
[
https://issues.apache.org/jira/browse/IGNITE-22061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22061:
-
Assignee: Pavel Pereslegin
> Use compact representation of BigDecimal with large scale for integers /
> numbers with trailing zeros
>
>
> Key: IGNITE-22061
> URL: https://issues.apache.org/jira/browse/IGNITE-22061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> BigDecimals that represent integer numbers can take up a lot of space, when
> scale is specified:
> {code:java}
> BigDecimal dc = new BigDecimal("").setScale(1024,
> RoundingMode.HALF_UP);
> System.out.println("Difference:");
> System.out.println(MarshallerUtil.sizeInBytes(dc) -
> dc.stripTrailingZeros().setScale(0,
> RoundingMode.HALF_UP).unscaledValue().toByteArray().length);
> {code}
> The code prints:
> {code}
> Difference:
> 427
> {code}
> Let's update BinaryTuple format to store such numbers in more compact form
> that does not store trailing zeros.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21167) Sql. Change exception message raised while calling transactions with disabled autoCommit from jdbc
[
https://issues.apache.org/jira/browse/IGNITE-21167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-21167:
-
Assignee: Pavel Pereslegin
> Sql. Change exception message raised while calling transactions with disabled
> autoCommit from jdbc
> --
>
> Key: IGNITE-21167
> URL: https://issues.apache.org/jira/browse/IGNITE-21167
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> After ignite-20661 was implemented, statements like:
> {code:java}
> "START TRANSACTION; SELECT 1; COMMIT;"
> {code}
> will throw non friendly exception like :
> "Transaction control statement cannot be executed within an external
> transaction"
> Need to be changed.
> Discussed in [1]
> [1] https://github.com/apache/ignite-3/pull/2906#discussion_r1420178983
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22000) Sql. Get rid of unnecessary conversion of DDL commands
[
https://issues.apache.org/jira/browse/IGNITE-22000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22000:
--
Summary: Sql. Get rid of unnecessary conversion of DDL commands (was: Sql.
Get rid of DdlSqlToCommandConverter)
> Sql. Get rid of unnecessary conversion of DDL commands
> --
>
> Key: IGNITE-22000
> URL: https://issues.apache.org/jira/browse/IGNITE-22000
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, refactoring
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Every DDL command goes through two levels of conversion now.
> From {{AST}} into {{DdlCommand}} using {{DdlSqlToCommandConverter}}.
> And from {{DdlCommand}} into {{CatalogCommand}} (using
> {{DdlToCatalogCommandConverter}}).
> It looks like we should do only single conversion {{AST}} =>
> {{CatalogCommand}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22162) Add support for using selected affinity function in distribution zones
[
https://issues.apache.org/jira/browse/IGNITE-22162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22162:
--
Labels: iep-101 ignite-3 (was: ignite-3)
> Add support for using selected affinity function in distribution zones
> --
>
> Key: IGNITE-22162
> URL: https://issues.apache.org/jira/browse/IGNITE-22162
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: iep-101, ignite-3
>
> According to
> [IEP-101|https://cwiki.apache.org/confluence/display/IGNITE/IEP-101%253A+Distribution+Zones]
> the user can select a different affinity function when creating a
> distribution zone.
> For example:
> {code:SQL}
> CREATE ZONE test WITH AFFINITY_FUNCTION='fair_affinity'...
> {code}
> The provided value is not currently processed in any way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22162) Add support for using selected affinity function in distribution zones
Pavel Pereslegin created IGNITE-22162:
-
Summary: Add support for using selected affinity function in
distribution zones
Key: IGNITE-22162
URL: https://issues.apache.org/jira/browse/IGNITE-22162
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Pereslegin
According to
[IEP-101|https://cwiki.apache.org/confluence/display/IGNITE/IEP-101%253A+Distribution+Zones]
the user can select a different affinity function when creating a distribution
zone.
For example:
{code:SQL}
CREATE ZONE test WITH AFFINITY_FUNCTION='fair_affinity'...
{code}
The provided value is not currently processed in any way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-22148) BinaryTupleFormatException for UUID
[ https://issues.apache.org/jira/browse/IGNITE-22148 ]
Pavel Pereslegin deleted comment on IGNITE-22148:
---
was (Author: xtern):
the following case should be also investigated (rand_uuid instead of
gen_random_uuid)
{code:java}
sql("create table tdd(a uuid default RAND_UUID, b int, primary key (a) )");
sql("insert into tdd(b) values(22)");
{code}
current output
{noformat}
Caused by: java.lang.IllegalArgumentException: No enum constant
org.apache.ignite.internal.schema.DefaultValueGenerator.RAND_UUID
at java.base/java.lang.Enum.valueOf(Enum.java:240) ~[?:?]
at
org.apache.ignite.internal.schema.DefaultValueGenerator.valueOf(DefaultValueGenerator.java:29)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:138)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:162)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaUtils.prepareSchemaDescriptor(SchemaUtils.java:37)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreatedOrAltered(SchemaManager.java:147)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreated(SchemaManager.java:119)
~[main/:?]
at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:83)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:532)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:499)
~[main/:?]
at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:310)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
~[main/:?]
... 6 more
{noformat}
> BinaryTupleFormatException for UUID
> ---
>
> Key: IGNITE-22148
> URL: https://issues.apache.org/jira/browse/IGNITE-22148
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> Simple example to reproduce the issue:
> {code:java}
> sql("create table tdd(a uuid default gen_random_uuid, b int, primary key (a)
> )");
> sql("insert into tdd(b) values(22)");{code}
> we got
> {code:java}
> Caused by: org.apache.ignite.internal.binarytuple.BinaryTupleFormatException:
> IGN-CMN-65535 TraceId:5dfdd34c-6722-41ad-85f3-13aa0c483454 Invalid length for
> a tuple element: 36
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleParser.uuidValue(BinaryTupleParser.java:377)
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleReader.uuidValue(BinaryTupleReader.java:305)
> at
> org.apache.ignite.internal.sql.engine.util.Commons.readValue(Commons.java:487)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlOutputBinaryRow.newRow(SqlOutputBinaryRow.java:85)
> at
> org.apache.ignite.internal.sql.engine.exec.TableRowConverterImpl.toBinaryRow(TableRowConverterImpl.java:83)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insert(UpdatableTableImpl.java:187)
> at
> org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$1(KeyValueModifyPlan.java:133)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22148) BinaryTupleFormatException for UUID
[
https://issues.apache.org/jira/browse/IGNITE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842365#comment-17842365
]
Pavel Pereslegin edited comment on IGNITE-22148 at 4/30/24 12:44 PM:
-
the following case should be also investigated (rand_uuid instead of
gen_random_uuid)
{code:java}
sql("create table tdd(a uuid default RAND_UUID, b int, primary key (a) )");
sql("insert into tdd(b) values(22)");
{code}
current output
{noformat}
Caused by: java.lang.IllegalArgumentException: No enum constant
org.apache.ignite.internal.schema.DefaultValueGenerator.RAND_UUID
at java.base/java.lang.Enum.valueOf(Enum.java:240) ~[?:?]
at
org.apache.ignite.internal.schema.DefaultValueGenerator.valueOf(DefaultValueGenerator.java:29)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:138)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:162)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaUtils.prepareSchemaDescriptor(SchemaUtils.java:37)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreatedOrAltered(SchemaManager.java:147)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreated(SchemaManager.java:119)
~[main/:?]
at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:83)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:532)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:499)
~[main/:?]
at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:310)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
~[main/:?]
... 6 more
{noformat}
was (Author: xtern):
the following case should be also investigated
{code:java}
sql("create table tdd(a uuid default RAND_UUID, b int, primary key (a) )");
sql("insert into tdd(b) values(22)");
{code}
current output
{noformat}
Caused by: java.lang.IllegalArgumentException: No enum constant
org.apache.ignite.internal.schema.DefaultValueGenerator.RAND_UUID
at java.base/java.lang.Enum.valueOf(Enum.java:240) ~[?:?]
at
org.apache.ignite.internal.schema.DefaultValueGenerator.valueOf(DefaultValueGenerator.java:29)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:138)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:162)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaUtils.prepareSchemaDescriptor(SchemaUtils.java:37)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreatedOrAltered(SchemaManager.java:147)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreated(SchemaManager.java:119)
~[main/:?]
at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:83)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:532)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:499)
~[main/:?]
at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:310)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
~[main/:?]
... 6 more
{noformat}
> BinaryTupleFormatException for UUID
> ---
>
> Key: IGNITE-22148
> URL: https://issues.apache.org/jira/browse/IGNITE-22148
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> Simple example to reproduce the issue:
> {code:java}
> sql("create table tdd(a uuid default
[jira] [Commented] (IGNITE-22148) BinaryTupleFormatException for UUID
[
https://issues.apache.org/jira/browse/IGNITE-22148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842365#comment-17842365
]
Pavel Pereslegin commented on IGNITE-22148:
---
the following case should be also investigated
{code:java}
sql("create table tdd(a uuid default RAND_UUID, b int, primary key (a) )");
sql("insert into tdd(b) values(22)");
{code}
current output
{noformat}
Caused by: java.lang.IllegalArgumentException: No enum constant
org.apache.ignite.internal.schema.DefaultValueGenerator.RAND_UUID
at java.base/java.lang.Enum.valueOf(Enum.java:240) ~[?:?]
at
org.apache.ignite.internal.schema.DefaultValueGenerator.valueOf(DefaultValueGenerator.java:29)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:138)
~[main/:?]
at
org.apache.ignite.internal.schema.catalog.CatalogToSchemaDescriptorConverter.convert(CatalogToSchemaDescriptorConverter.java:162)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaUtils.prepareSchemaDescriptor(SchemaUtils.java:37)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreatedOrAltered(SchemaManager.java:147)
~[main/:?]
at
org.apache.ignite.internal.schema.SchemaManager.onTableCreated(SchemaManager.java:119)
~[main/:?]
at
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:83)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:532)
~[main/:?]
at
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:499)
~[main/:?]
at
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:310)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
~[main/:?]
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
~[main/:?]
... 6 more
{noformat}
> BinaryTupleFormatException for UUID
> ---
>
> Key: IGNITE-22148
> URL: https://issues.apache.org/jira/browse/IGNITE-22148
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> Simple example to reproduce the issue:
> {code:java}
> sql("create table tdd(a uuid default gen_random_uuid, b int, primary key (a)
> )");
> sql("insert into tdd(b) values(22)");{code}
> we got
> {code:java}
> Caused by: org.apache.ignite.internal.binarytuple.BinaryTupleFormatException:
> IGN-CMN-65535 TraceId:5dfdd34c-6722-41ad-85f3-13aa0c483454 Invalid length for
> a tuple element: 36
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleParser.uuidValue(BinaryTupleParser.java:377)
> at
> org.apache.ignite.internal.binarytuple.BinaryTupleReader.uuidValue(BinaryTupleReader.java:305)
> at
> org.apache.ignite.internal.sql.engine.util.Commons.readValue(Commons.java:487)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlOutputBinaryRow.newRow(SqlOutputBinaryRow.java:85)
> at
> org.apache.ignite.internal.sql.engine.exec.TableRowConverterImpl.toBinaryRow(TableRowConverterImpl.java:83)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insert(UpdatableTableImpl.java:187)
> at
> org.apache.ignite.internal.sql.engine.prepare.KeyValueModifyPlan.lambda$execute$1(KeyValueModifyPlan.java:133)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1187)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22000) Sql. Get rid of DdlSqlToCommandConverter
[
https://issues.apache.org/jira/browse/IGNITE-22000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22000:
-
Assignee: Pavel Pereslegin
> Sql. Get rid of DdlSqlToCommandConverter
>
>
> Key: IGNITE-22000
> URL: https://issues.apache.org/jira/browse/IGNITE-22000
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, refactoring
>
> Every DDL command goes through two levels of conversion now.
> From {{AST}} into {{DdlCommand}} using {{DdlSqlToCommandConverter}}.
> And from {{DdlCommand}} into {{CatalogCommand}} (using
> {{DdlToCatalogCommandConverter}}).
> It looks like we should do only single conversion {{AST}} =>
> {{CatalogCommand}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-17440) SQL API should use Statements parameters in Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-17440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin resolved IGNITE-17440. --- Resolution: Duplicate resolved in IGNITE-18647 > SQL API should use Statements parameters in Ignite 3 > > > Key: IGNITE-17440 > URL: https://issues.apache.org/jira/browse/IGNITE-17440 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We don't use any parameters from Statements except a query text for execution > query throuht Session. So no any parameters like a timeout, schema and so > one is used. > Need to implement pass the parameters to server and start use it. > Start point is org.apache.ignite.internal.sql.api.SessionImpl#executeAsync -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21822) Sql. Allow to set time zone on per statement basis
[ https://issues.apache.org/jira/browse/IGNITE-21822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin resolved IGNITE-21822. --- Resolution: Duplicate resolved in IGNITE-18647 > Sql. Allow to set time zone on per statement basis > -- > > Key: IGNITE-21822 > URL: https://issues.apache.org/jira/browse/IGNITE-21822 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > In IGNITE-21551, support for time zone was added to the sql engine. However, > only Session was updated, while Statement was left intact. Let's eliminate > such a discrepancy by providing an ability to set time zone on per statement > basis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21940) Cover SQL F304(EXCEPT ALL table operator) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839488#comment-17839488 ] Pavel Pereslegin commented on IGNITE-21940: --- [~jooger], take a look at this patch, please. > Cover SQL F304(EXCEPT ALL table operator) feature by tests > -- > > Key: IGNITE-21940 > URL: https://issues.apache.org/jira/browse/IGNITE-21940 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We don't have at all any tests for F304(EXCEPT ALL table operator) SQL > feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21939) Cover SQL F302-02(INTERSECT table operator. INTERSECT ALL table operator) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839487#comment-17839487 ] Pavel Pereslegin commented on IGNITE-21939: --- [~jooger], take a look at this patch, please. > Cover SQL F302-02(INTERSECT table operator. INTERSECT ALL table operator) > feature by tests > -- > > Key: IGNITE-21939 > URL: https://issues.apache.org/jira/browse/IGNITE-21939 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We don't have at all any tests for F302-02(INTERSECT table operator. > INTERSECT ALL table operator) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin resolved IGNITE-21996.
---
Resolution: Cannot Reproduce
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reopened IGNITE-21996:
---
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21939) Cover SQL F302-02(INTERSECT table operator. INTERSECT ALL table operator) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-21939: - Assignee: Pavel Pereslegin > Cover SQL F302-02(INTERSECT table operator. INTERSECT ALL table operator) > feature by tests > -- > > Key: IGNITE-21939 > URL: https://issues.apache.org/jira/browse/IGNITE-21939 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F302-02(INTERSECT table operator. > INTERSECT ALL table operator) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21940) Cover SQL F304(EXCEPT ALL table operator) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-21940: - Assignee: Pavel Pereslegin > Cover SQL F304(EXCEPT ALL table operator) feature by tests > -- > > Key: IGNITE-21940 > URL: https://issues.apache.org/jira/browse/IGNITE-21940 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > We don't have at all any tests for F304(EXCEPT ALL table operator) SQL > feature. > Let's cover it and create tickets to fix them in case find any issues related > to the covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19082) Catalog. Cleanup dead code.
[ https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-19082: - Assignee: (was: Pavel Pereslegin) > Catalog. Cleanup dead code. > --- > > Key: IGNITE-19082 > URL: https://issues.apache.org/jira/browse/IGNITE-19082 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's > * ensure Catalog is used by default as a single schema management point by > TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. > * drop schema related code from configuration. > * drop outdated code from TableManager, IndexManager, SqlSchemaManager, > SchemaRegistry. > * make a PR for merging feature branch to main (if applicable). > * ensure there are end-to-end tests for the cases (if applicable) described > in CatalogServiceSelfTest. Also drop InternalSchemaTest. > * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry > class as example) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19082) Catalog. Cleanup dead code.
[ https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-19082: - Assignee: Pavel Pereslegin > Catalog. Cleanup dead code. > --- > > Key: IGNITE-19082 > URL: https://issues.apache.org/jira/browse/IGNITE-19082 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's > * ensure Catalog is used by default as a single schema management point by > TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. > * drop schema related code from configuration. > * drop outdated code from TableManager, IndexManager, SqlSchemaManager, > SchemaRegistry. > * make a PR for merging feature branch to main (if applicable). > * ensure there are end-to-end tests for the cases (if applicable) described > in CatalogServiceSelfTest. Also drop InternalSchemaTest. > * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry > class as example) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22073) Sql. Add processing of the provided query timeout
Pavel Pereslegin created IGNITE-22073:
-
Summary: Sql. Add processing of the provided query timeout
Key: IGNITE-22073
URL: https://issues.apache.org/jira/browse/IGNITE-22073
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Pavel Pereslegin
Public org.apache.ignite.sql.Statement contains {{queryTimeout}} parameter,
which user can change using {{StatementBuilder}}.
{code:java}
/**
* Sets a query timeout.
*
* @param timeout Query timeout value.
* @param timeUnit Timeunit.
* @return {@code this} for chaining.
*/
StatementBuilder queryTimeout(long timeout, TimeUnit timeUnit);
{code}
I'm guessing that by using this option the user can expect the query to be
aborted when it times out. We need to implement handling of this option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18492) SQL: Inconsistent behavior of LENGTH limit for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-18492:
--
Description:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the word VARCHAR)^{color}
was:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
> SQL: Inconsistent behavior of LENGTH limit for CHAR data type
> -
>
> Key: IGNITE-18492
> URL: https://issues.apache.org/jira/browse/IGNITE-18492
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When I create a table with {{CHAR(length)}} column, it's still possible to
> insert character values with length greater than given limit.
> {code:sql}
> sql-cli> create table xx (pk int primary key, f1 char(5));
> Updated 0 rows.
> sql-cli> insert into xx values (1, 'abcdefgh');
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> In other hand, length limit is applied when I insert non-char value that's
> casted into {{CHAR}} implicitly. With the same table as above:
> {code:sql}
> sql-cli> insert into xx values (2, 1234567);
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 2 │ 12345║
> ╟┼──╢
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> Behavior should be consistent: ether strip both values down to the given
> length limit, or deny to insert too long values in both cases (like it's done
> in other DBs, like postgresql).
>
> Dynamic params can be processed to, check
> IgniteSqlValidator#inferDynamicParamType
> NOTE
> VARCHAR is also affected
> {color:#505f79}^(the note was added so that the ticket would be included in
> the search for the word VARCHAR)^{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18492) SQL: Inconsistent behavior of LENGTH limit for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-18492:
--
Description:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(this note was added so that the ticket would be included in
the search for the keyword VARCHAR)^{color}
was:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the keyword VARCHAR)^{color}
> SQL: Inconsistent behavior of LENGTH limit for CHAR data type
> -
>
> Key: IGNITE-18492
> URL: https://issues.apache.org/jira/browse/IGNITE-18492
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When I create a table with {{CHAR(length)}} column, it's still possible to
> insert character values with length greater than given limit.
> {code:sql}
> sql-cli> create table xx (pk int primary key, f1 char(5));
> Updated 0 rows.
> sql-cli> insert into xx values (1, 'abcdefgh');
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> In other hand, length limit is applied when I insert non-char value that's
> casted into {{CHAR}} implicitly. With the same table as above:
> {code:sql}
> sql-cli> insert into xx values (2, 1234567);
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 2 │ 12345║
> ╟┼──╢
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> Behavior should be consistent: ether strip both values down to the given
> length limit, or deny to insert too long values in both cases (like it's done
> in other DBs, like postgresql).
>
> Dynamic params can be processed to, check
> IgniteSqlValidator#inferDynamicParamType
> NOTE
> VARCHAR is also affected
> {color:#505f79}^(this note was added so that the ticket would be included in
> the search for the keyword VARCHAR)^{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18492) SQL: Inconsistent behavior of LENGTH limit for CHAR data type
[
https://issues.apache.org/jira/browse/IGNITE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-18492:
--
Description:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the keyword VARCHAR)^{color}
was:
When I create a table with {{CHAR(length)}} column, it's still possible to
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 1 │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1 ║
╠╪══╣
║ 2 │ 12345║
╟┼──╢
║ 1 │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length
limit, or deny to insert too long values in both cases (like it's done in other
DBs, like postgresql).
Dynamic params can be processed to, check
IgniteSqlValidator#inferDynamicParamType
NOTE
VARCHAR is also affected
{color:#505f79}^(the note was added so that the ticket would be included in the
search for the word VARCHAR)^{color}
> SQL: Inconsistent behavior of LENGTH limit for CHAR data type
> -
>
> Key: IGNITE-18492
> URL: https://issues.apache.org/jira/browse/IGNITE-18492
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When I create a table with {{CHAR(length)}} column, it's still possible to
> insert character values with length greater than given limit.
> {code:sql}
> sql-cli> create table xx (pk int primary key, f1 char(5));
> Updated 0 rows.
> sql-cli> insert into xx values (1, 'abcdefgh');
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> In other hand, length limit is applied when I insert non-char value that's
> casted into {{CHAR}} implicitly. With the same table as above:
> {code:sql}
> sql-cli> insert into xx values (2, 1234567);
> Updated 1 rows.
> sql-cli> select * from xx;
> ╔╤══╗
> ║ PK │ F1 ║
> ╠╪══╣
> ║ 2 │ 12345║
> ╟┼──╢
> ║ 1 │ abcdefgh ║
> ╚╧══╝
> {code}
> Behavior should be consistent: ether strip both values down to the given
> length limit, or deny to insert too long values in both cases (like it's done
> in other DBs, like postgresql).
>
> Dynamic params can be processed to, check
> IgniteSqlValidator#inferDynamicParamType
> NOTE
> VARCHAR is also affected
> {color:#505f79}^(the note was added so that the ticket would be included in
> the search for the keyword VARCHAR)^{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21996:
--
Ignite Flags: (was: Docs Required)
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18647) SQL API: Implement missed Statement and StatementBuilder methods.
[ https://issues.apache.org/jira/browse/IGNITE-18647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-18647: -- Fix Version/s: 3.0.0-beta2 > SQL API: Implement missed Statement and StatementBuilder methods. > - > > Key: IGNITE-18647 > URL: https://issues.apache.org/jira/browse/IGNITE-18647 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Pavel Pereslegin >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21996:
--
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21996) Sql. SET DATA TYPE command allow change from null to not null
[
https://issues.apache.org/jira/browse/IGNITE-21996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-21996:
-
Assignee: Pavel Pereslegin
> Sql. SET DATA TYPE command allow change from null to not null
> -
>
> Key: IGNITE-21996
> URL: https://issues.apache.org/jira/browse/IGNITE-21996
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Iurii Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> As of now absent validation during the amend column from NULLABLE to NOT
> NULLABLE in case using DDL command
> {code:java}
> ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE NOT NULL ...{code}
>
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21822) Sql. Allow to set time zone on per statement basis
[ https://issues.apache.org/jira/browse/IGNITE-21822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-21822: - Assignee: Pavel Pereslegin > Sql. Allow to set time zone on per statement basis > -- > > Key: IGNITE-21822 > URL: https://issues.apache.org/jira/browse/IGNITE-21822 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > In IGNITE-21551, support for time zone was added to the sql engine. However, > only Session was updated, while Statement was left intact. Let's eliminate > such a discrepancy by providing an ability to set time zone on per statement > basis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18647) SQL API: Implement missed Statement and StatementBuilder methods.
[ https://issues.apache.org/jira/browse/IGNITE-18647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-18647: - Assignee: Pavel Pereslegin > SQL API: Implement missed Statement and StatementBuilder methods. > - > > Key: IGNITE-18647 > URL: https://issues.apache.org/jira/browse/IGNITE-18647 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Pavel Pereslegin >Priority: Critical > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19687) Support default distribution zone reassignment in Catalog
[
https://issues.apache.org/jira/browse/IGNITE-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19687:
--
Fix Version/s: 3.0.0-beta2
> Support default distribution zone reassignment in Catalog
> -
>
> Key: IGNITE-19687
> URL: https://issues.apache.org/jira/browse/IGNITE-19687
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> *Motivation.*
> We have no reasonable arguments that we need a special distribution zone
> instance. All distribution zones are equals. Thus, conceptually, any zone can
> be used as default one and can be renamed.
> For better UX, we still can require at least one distribution zone, which is
> currently assigned as default zone, must always exists.
> Let's
> * Avoid using any hardcoded zone id or zone name for getting or detecting the
> default distribution zone.
> * Distributed zone manager shouldn't care which zone is default. Catalog will
> be responsible for resolving default zone if it is not specified when table
> is creating.
> * Add a property in Catalog that will store default zone by zone id.
> * Forbid dropping of distribution zone, which is currently marked as default.
> h3. *Implementation notes*
> We need to enhance {{org.apache.ignite.internal.catalog.Catalog#Catalog}}
> with the default zone id, so when {{UpdateEntry#applyUpdate}} will recreate
> Catalog for a SQL command of setting default zone, the new zone id could be
> saved to Catalog state.
> Also tests must be added here like tests for altering zone and checking that
> tables will use the new default zone, test validation for dropping of
> distribution zone, which is currently marked as default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19687) Support default distribution zone reassignment in Catalog
[
https://issues.apache.org/jira/browse/IGNITE-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19687:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Support default distribution zone reassignment in Catalog
> -
>
> Key: IGNITE-19687
> URL: https://issues.apache.org/jira/browse/IGNITE-19687
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> *Motivation.*
> We have no reasonable arguments that we need a special distribution zone
> instance. All distribution zones are equals. Thus, conceptually, any zone can
> be used as default one and can be renamed.
> For better UX, we still can require at least one distribution zone, which is
> currently assigned as default zone, must always exists.
> Let's
> * Avoid using any hardcoded zone id or zone name for getting or detecting the
> default distribution zone.
> * Distributed zone manager shouldn't care which zone is default. Catalog will
> be responsible for resolving default zone if it is not specified when table
> is creating.
> * Add a property in Catalog that will store default zone by zone id.
> * Forbid dropping of distribution zone, which is currently marked as default.
> h3. *Implementation notes*
> We need to enhance {{org.apache.ignite.internal.catalog.Catalog#Catalog}}
> with the default zone id, so when {{UpdateEntry#applyUpdate}} will recreate
> Catalog for a SQL command of setting default zone, the new zone id could be
> saved to Catalog state.
> Also tests must be added here like tests for altering zone and checking that
> tables will use the new default zone, test validation for dropping of
> distribution zone, which is currently marked as default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Component/s: jdbc
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH LOCAL TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is a poor implementation of java.sql.Timestamp (and
> java.util.Date).
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
> different timestamps for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-21136:
-
Assignee: (was: Pavel Pereslegin)
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin edited comment on IGNITE-21136 at 4/17/24 9:51 AM:
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
was (Author: xtern):
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still recommended to add
the TO_CHAR (and TO_TIMESTAMP) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin edited comment on IGNITE-21136 at 4/17/24 9:59 AM:
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
(anyway it worth to wait calcite 1.37, because currently {{TO_CHAR}} produces
invalid results for some cases, see CALCITE-6252)
was (Author: xtern):
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
(anyway it worth to wait calcite 1.37, because currently this function works
incorrectly for some cases see CALCITE-6252)
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin edited comment on IGNITE-21136 at 4/17/24 9:57 AM:
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
(anyway it worth to wait calcite 1.37, because currently this function works
incorrectly for some cases see CALCITE-6252)
was (Author: xtern):
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still worth to enable the
{{TO_CHAR}} (and {{TO_TIMESTAMP}}) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838071#comment-17838071
]
Pavel Pereslegin commented on IGNITE-21136:
---
We need to investigate if we can support setting FORMAT TEMPLATE using a
dynamic parameter.
If we can’t or it’s extremely complicated, then it is still recommended to add
the TO_CHAR (and TO_TIMESTAMP) function.
Example of sql logic test for to_char function
https://gist.github.com/xtern/bc9050cce469565ca4ba5b8c3a623c92
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH LOCAL TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp (and
java.util.Date).
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
different timestamps for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp (and
java.util.Date).
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
different timestamps for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH LOCAL TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
>
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp (and
java.util.Date).
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} may create
different timestamps for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt =
[jira] [Comment Edited] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837797#comment-17837797
]
Pavel Pereslegin edited comment on IGNITE-22056 at 4/16/24 4:54 PM:
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{code:java}
instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()
{code}
because of [this|https://joda-time.sourceforge.net/faq.html#wrongoffset]
Something like this seems to work (need to double check it with DST timestamps)
{code:java}
instant.plusMillis(timeZone.getOffset(timestamp -
timeZone.getOffset(timestamp))).atZone(ZoneId.of("UTC")).toLocalDateTime()
{code}
was (Author: xtern):
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{code:java}
instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()
{code}
because of [this|https://joda-time.sourceforge.net/faq.html#wrongoffset]
Something like this seems to work
{code:java}
instant.plusMillis(timeZone.getOffset(timestamp -
timeZone.getOffset(timestamp))).atZone(ZoneId.of("UTC")).toLocalDateTime()
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is a poor implementation of java.sql.Timestamp.
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
> different timestamps, even for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837797#comment-17837797
]
Pavel Pereslegin commented on IGNITE-22056:
---
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{code:java}
instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()
{code}
because of [this|https://joda-time.sourceforge.net/faq.html#wrongoffset]
Something like this seems to work
{code:java}
instant.plusMillis(timeZone.getOffset(timestamp -
timeZone.getOffset(timestamp))).atZone(ZoneId.of("UTC")).toLocalDateTime()
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is a poor implementation of java.sql.Timestamp.
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
> different timestamps, even for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{code:java}
instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()
{code}
because of [this|https://joda-time.sourceforge.net/faq.html#wrongoffset]
Something like this seems to work
{code:java}
instant.plusMillis(timeZone.getOffset(timestamp -
timeZone.getOffset(timestamp))).atZone(ZoneId.of("UTC")).toLocalDateTime()
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
>
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{code:java}
instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()
{code}
because of [this|https://joda-time.sourceforge.net/faq.html#wrongoffset]
Something like this seems to work
{code:java}
instant.plusMillis(timeZone.getOffset(timestamp -
timeZone.getOffset(timestamp))).atZone(ZoneId.of("UTC")).toLocalDateTime()
{code}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{{instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()}} because
of [this|https://joda-time.sourceforge.net/faq.html#wrongoffset]
Something like this seems to work
{{instant.plusMillis(timeZone.getOffset(timestamp -
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{{instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()}} because
of [this|https://joda-time.sourceforge.net/faq.html#wrongoffset]
Something like this seems to work
{{instant.plusMillis(timeZone.getOffset(timestamp -
timeZone.getOffset(timestamp))).atZone(ZoneId.of("UTC")).toLocalDateTime()}}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{{instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()}} because
of [link title|http://example.com]
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
>
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
Looks like this can be resolved converting Instant to LocalDateTime and
creating timestamp from it (in getResultSet method).
But we can't use simple
{{instant.atZone(TimeZone.getDefault().toZoneId()).toLocalDateTime()}} because
of [link title|http://example.com]
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
>
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is a poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt =
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (before 1900 year), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (*before 1900 year*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900 year), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt =
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (*before 1900 year*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (*before 1900 years*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (*before 1900 year*), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt =
[jira] [Updated] (IGNITE-22056) Sql. Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Summary: Sql. Jdbc. Incorrect value can be read for a column with Instant.
(was: Jdbc. Incorrect value can be read for a column with Instant.)
> Sql. Jdbc. Incorrect value can be read for a column with Instant.
> -
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (*before 1900 years*), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is the poor implementation of java.sql.Timestamp.
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
> different timestamps, even for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (*before 1900 years*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (*before 1900 years*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
LocalDateTime ldt = LocalDateTime.parse("1581-12-31T00:00:00");
assertEquals(ldt, rs.getObject("dt"));
assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
rs.getObject("ts"));
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
> Jdbc. Incorrect value can be read for a column with Instant.
>
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (*before 1900 years*), we can get the incorrect value using the
> {{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE).
> Reproducer
> {code:java}
> @Test
> public void
[jira] [Updated] (IGNITE-22056) Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (*before 1900 years*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
LocalDateTime ldt = LocalDateTime.parse("1581-12-31T00:00:00");
assertEquals(ldt, rs.getObject("dt"));
assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
rs.getObject("ts"));
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime()); // fails
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (*before 1900 years*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
LocalDateTime ldt = LocalDateTime.parse("1581-12-31T00:00:00");
assertEquals(ldt, rs.getObject("dt"));
assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
rs.getObject("ts"));
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
// This alidation fails.
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime());
// Expected :-1224417600
// Actual :-1224331200
{code}
> Jdbc. Incorrect value can be read for a column with Instant.
>
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
>
[jira] [Updated] (IGNITE-22056) Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Description:
For dates (*before 1900 years*), we can get the incorrect value using the
{{ResultSet#getTimestamp}} method (for a column with Instant value (TIMESTAMP
WITH TIME ZONE).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
LocalDateTime ldt = LocalDateTime.parse("1581-12-31T00:00:00");
assertEquals(ldt, rs.getObject("dt"));
assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
rs.getObject("ts"));
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
// This alidation fails.
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime());
// Expected :-1224417600
// Actual :-1224331200
{code}
was:
For dates (before 1900), we can get the incorrect value using the
ResultSet#getTimestamp method (for a column with Instant value (TIMESTAMP WITH
TIME ZONE) ).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
LocalDateTime ldt = LocalDateTime.parse("1581-12-31T00:00:00");
assertEquals(ldt, rs.getObject("dt"));
assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
rs.getObject("ts"));
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
// This alidation fails.
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime());
// Expected :-1224417600
// Actual :-1224331200
{code}
> Jdbc. Incorrect value can be read for a column with Instant.
>
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
>
[jira] [Updated] (IGNITE-22056) Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Labels: ignite-3 (was: )
> Jdbc. Incorrect value can be read for a column with Instant.
>
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900), we can get the incorrect value using the
> ResultSet#getTimestamp method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE) ).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> LocalDateTime ldt =
> LocalDateTime.parse("1581-12-31T00:00:00");
> assertEquals(ldt, rs.getObject("dt"));
> assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
> rs.getObject("ts"));
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is the poor implementation of java.sql.Timestamp.
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
> different timestamps, even for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> // This alidation fails.
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime());
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Component/s: sql
> Jdbc. Incorrect value can be read for a column with Instant.
>
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> For dates (before 1900), we can get the incorrect value using the
> ResultSet#getTimestamp method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE) ).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> LocalDateTime ldt =
> LocalDateTime.parse("1581-12-31T00:00:00");
> assertEquals(ldt, rs.getObject("dt"));
> assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
> rs.getObject("ts"));
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is the poor implementation of java.sql.Timestamp.
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
> different timestamps, even for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> // This alidation fails.
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime());
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22056) Jdbc. Incorrect value can be read for a column with Instant.
[
https://issues.apache.org/jira/browse/IGNITE-22056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22056:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Jdbc. Incorrect value can be read for a column with Instant.
>
>
> Key: IGNITE-22056
> URL: https://issues.apache.org/jira/browse/IGNITE-22056
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Major
>
> For dates (before 1900), we can get the incorrect value using the
> ResultSet#getTimestamp method (for a column with Instant value (TIMESTAMP
> WITH TIME ZONE) ).
> Reproducer
> {code:java}
> @Test
> public void testTimestamps() throws SQLException {
> // Ignoring time zone.
> TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
> try (Connection conn = DriverManager.getConnection(URL)) {
> try (Statement stmt = conn.createStatement()) {
> stmt.execute(
> "CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
> timestamp with local time zone);"
> + "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
> '1581-12-31 00:00:00')"
> );
> }
> try (Statement stmt = conn.createStatement()) {
> try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
> assertTrue(rs.next());
> LocalDateTime ldt =
> LocalDateTime.parse("1581-12-31T00:00:00");
> assertEquals(ldt, rs.getObject("dt"));
> assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
> rs.getObject("ts"));
> Timestamp tsFromDateTime = rs.getTimestamp("dt");
> Timestamp tsFromTimestamp = rs.getTimestamp("ts");
> assertEquals(tsFromDateTime, tsFromTimestamp); // fails
> // Expected :1581-12-31 00:00:00.0
> // Actual :1581-12-21 00:00:00.0
> }
> }
> }
> }
> {code}
> The main problem is the poor implementation of java.sql.Timestamp.
> To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
> different timestamps, even for the same dates.
> {code:java}
> TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
> Instant instant = Instant.parse("1581-12-31T00:00:00Z");
> LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
> ZoneId.of("UTC"));
> Timestamp rightMillisTs = Timestamp.from(instant);
> Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
> // This alidation fails.
> assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime());
> // Expected :-1224417600
> // Actual :-1224331200
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22056) Jdbc. Incorrect value can be read for a column with Instant.
Pavel Pereslegin created IGNITE-22056:
-
Summary: Jdbc. Incorrect value can be read for a column with
Instant.
Key: IGNITE-22056
URL: https://issues.apache.org/jira/browse/IGNITE-22056
Project: Ignite
Issue Type: Bug
Reporter: Pavel Pereslegin
For dates (before 1900), we can get the incorrect value using the
ResultSet#getTimestamp method (for a column with Instant value (TIMESTAMP WITH
TIME ZONE) ).
Reproducer
{code:java}
@Test
public void testTimestamps() throws SQLException {
// Ignoring time zone.
TimeZone.setDefault(TimeZone.getTimeZone(ZoneId.of("UTC")));
try (Connection conn = DriverManager.getConnection(URL)) {
try (Statement stmt = conn.createStatement()) {
stmt.execute(
"CREATE TABLE t (tt_id INT PRIMARY KEY, dt timestamp, ts
timestamp with local time zone);"
+ "INSERT INTO t VALUES(0, '1581-12-31 00:00:00',
'1581-12-31 00:00:00')"
);
}
try (Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("select dt, ts from t")) {
assertTrue(rs.next());
LocalDateTime ldt = LocalDateTime.parse("1581-12-31T00:00:00");
assertEquals(ldt, rs.getObject("dt"));
assertEquals(ldt.atOffset(ZoneOffset.UTC).toInstant(),
rs.getObject("ts"));
Timestamp tsFromDateTime = rs.getTimestamp("dt");
Timestamp tsFromTimestamp = rs.getTimestamp("ts");
assertEquals(tsFromDateTime, tsFromTimestamp); // fails
// Expected :1581-12-31 00:00:00.0
// Actual :1581-12-21 00:00:00.0
}
}
}
}
{code}
The main problem is the poor implementation of java.sql.Timestamp.
To be specific, {{valueOf(LocalDateTime)}} and {{from(Instant)}} constructs
different timestamps, even for the same dates.
{code:java}
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Instant instant = Instant.parse("1581-12-31T00:00:00Z");
LocalDateTime localDateTime = LocalDateTime.ofInstant(instant,
ZoneId.of("UTC"));
Timestamp rightMillisTs = Timestamp.from(instant);
Timestamp wrongMillisTs = Timestamp.valueOf(localDateTime);
// This alidation fails.
assertEquals(rightMillisTs.getTime(), wrongMillisTs.getTime());
// Expected :-1224417600
// Actual :-1224331200
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-21136:
-
Assignee: Pavel Pereslegin
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837158#comment-17837158
]
Pavel Pereslegin edited comment on IGNITE-21136 at 4/15/24 10:07 AM:
-
Looks like it's worth waiting for the next release of Calcite (1.37.0).
Because the FORMAT clause of the CAST operator is implemented there according
to SQL:2016 spec (CALCITE-2980).
was (Author: xtern):
Looks like it's worth waiting for the next release of Calcite (1.37.0).
Because the FORMAT clause of the CAST operator is implemented there
(CALCITE-2980).
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21136) SQL: implement functions for date/time formatting
[
https://issues.apache.org/jira/browse/IGNITE-21136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837158#comment-17837158
]
Pavel Pereslegin commented on IGNITE-21136:
---
Looks like it's worth waiting for the next release of Calcite (1.37.0).
Because the FORMAT clause of the CAST operator is implemented there
(CALCITE-2980).
> SQL: implement functions for date/time formatting
> -
>
> Key: IGNITE-21136
> URL: https://issues.apache.org/jira/browse/IGNITE-21136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3, sql
>
> SQL functions for date/time formatting are useful in many cases. In AI2, we
> have an universal FORMATDATETIME function for such purposes:
> {code:sql}
> SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
> {code}
> Please imlpement simliar functions in AI3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21976) Sql. Amend TREE keyword to SORTED for CREATE INDEX syntax
[ https://issues.apache.org/jira/browse/IGNITE-21976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837087#comment-17837087 ] Pavel Pereslegin commented on IGNITE-21976: --- [~jooger], take a look at the proposed changes, please. > Sql. Amend TREE keyword to SORTED for CREATE INDEX syntax > - > > Key: IGNITE-21976 > URL: https://issues.apache.org/jira/browse/IGNITE-21976 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > After IGNITE-21353 we can use syntax to choose the type of PK index as SORTED > or HASH, but we still have different keywords for CREATE INDEX syntax where > we should use TREE or HASH types. Let's have the same keyword for the sorted > index. > So, required to rename TREE to SORTED for CREATE INDEX syntax -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21976) Sql. Amend TREE keyword to SORTED for CREATE INDEX syntax
[ https://issues.apache.org/jira/browse/IGNITE-21976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-21976: - Assignee: Pavel Pereslegin > Sql. Amend TREE keyword to SORTED for CREATE INDEX syntax > - > > Key: IGNITE-21976 > URL: https://issues.apache.org/jira/browse/IGNITE-21976 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > After IGNITE-21353 we can use syntax to choose the type of PK index as SORTED > or HASH, but we still have different keywords for CREATE INDEX syntax where > we should use TREE or HASH types. Let's have the same keyword for the sorted > index. > So, required to rename TREE to SORTED for CREATE INDEX syntax -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22023) Sql. Support Json aggregate functions
[
https://issues.apache.org/jira/browse/IGNITE-22023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22023:
--
Description:
JSON aggregate functions ({{json_objectagg}} and {{json_arrayagg}}) are
supported in calcite, but they fail in Ignite 3 with "Illegal aggregate
function" exception.
{code:java}
// CREATE TABLE t(id INT PRIMARY KEY, val INT);
// INSERT INTO t VALUES (1, 1);
assertQuery("SELECT JSON_OBJECTAGG(id: val) FROM t")
.returns("{\"1\":1}")
.check();
{code}
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 8 to line 1, column 30: Illegal aggregate function.
JSON_OBJECTAGG_NULL_ON_NULL is unsupported at the moment
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5517)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateAggregateFunction(IgniteSqlValidator.java:823)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateAggregateParams(IgniteSqlValidator.java:537)
at
org.apache.calcite.sql.SqlAggFunction.validateCall(SqlAggFunction.java:137)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6232)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:143)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:275)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4714)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4679)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3840)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:466)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1154)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1125)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:282)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1091)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:797)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:179)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:283)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$3(PrepareServiceImpl.java:315)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
... 3 more
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Illegal
aggregate function. JSON_OBJECTAGG_NULL_ON_NULL is unsupported at the moment
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:601)
... 27 more
{noformat}
was:
JSON aggregate functions ({{json_objectagg}} and {{json_arrayagg}}) are
supported in calcite, but they fail in Ignite 3 with "Illegal aggregate
function" exception.
{code:java}
assertQuery("SELECT JSON_OBJECTAGG(id: val) FROM t")
.returns("{\"1\":1}")
.check();
{code}
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 8 to line 1, column 30: Illegal aggregate function.
JSON_OBJECTAGG_NULL_ON_NULL is unsupported at the moment
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5517)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateAggregateFunction(IgniteSqlValidator.java:823)
at
[jira] [Created] (IGNITE-22023) Sql. Support Json aggregate functions
Pavel Pereslegin created IGNITE-22023:
-
Summary: Sql. Support Json aggregate functions
Key: IGNITE-22023
URL: https://issues.apache.org/jira/browse/IGNITE-22023
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Pavel Pereslegin
JSON aggregate functions ({{json_objectagg}} and {{json_arrayagg}}) are
supported in calcite, but they fail in Ignite 3 with "Illegal aggregate
function" exception.
{code:java}
assertQuery("SELECT JSON_OBJECTAGG(id: val) FROM t")
.returns("{\"1\":1}")
.check();
{code}
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
column 8 to line 1, column 30: Illegal aggregate function.
JSON_OBJECTAGG_NULL_ON_NULL is unsupported at the moment
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5517)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateAggregateFunction(IgniteSqlValidator.java:823)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateAggregateParams(IgniteSqlValidator.java:537)
at
org.apache.calcite.sql.SqlAggFunction.validateCall(SqlAggFunction.java:137)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6232)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:143)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:275)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4714)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4679)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3840)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:466)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:61)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:88)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1154)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1125)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:282)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1091)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:797)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:179)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:283)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$3(PrepareServiceImpl.java:315)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
... 3 more
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Illegal
aggregate function. JSON_OBJECTAGG_NULL_ON_NULL is unsupported at the moment
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:601)
... 27 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22022) Sql. Json object with nested object creation fails
[
https://issues.apache.org/jira/browse/IGNITE-22022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22022:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Json object with nested object creation fails
> --
>
> Key: IGNITE-22022
> URL: https://issues.apache.org/jira/browse/IGNITE-22022
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {{json_object}} function fails when trying to create object with nested object
> {code:java}
> assertQuery("select json_object('name': 'Alex', 'address':
> json_object('city': 'City 17', 'street': 'Elm'))")
> .returns("{\"name\":\"Alex\",\"address\":{\"city\":\"City
> 17\",\"street\":\"Elm\"}}")
> .check();
> {code}
> {noformat}
> Caused by: java.lang.reflect.UndeclaredThrowableException
> at com.sun.proxy.$Proxy96.getExpressionList(Unknown Source)
> at org.apache.calcite.rel.core.Project.(Project.java:142)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteProject.(IgniteProject.java:83)
> at SC.apply(Unknown Source)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson$RelFactory.apply(RelJson.java:128)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.readRel(RelJsonReader.java:140)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.readRels(RelJsonReader.java:132)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.read(RelJsonReader.java:123)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.fromJson(RelJsonReader.java:86)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$relationalTreeFromJsonString$6(ExecutionServiceImpl.java:300)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.relationalTreeFromJsonString(ExecutionServiceImpl.java:298)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.submitFragment(ExecutionServiceImpl.java:833)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.submitFragment(ExecutionServiceImpl.java:514)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:413)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$1(ExecutionServiceImpl.java:262)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:151)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:115)
> ... 4 more
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.ignite.internal.sql.engine.trait.TraitUtils.lambda$changeTraits$0(TraitUtils.java:265)
> ... 26 more
> Caused by: java.lang.NullPointerException: operator
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at org.apache.calcite.rex.RexCall.(RexCall.java:81)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:258)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:828)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRexList(RelJson.java:1027)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:787)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:303)
> ... 28 more
> {noformat}
> At first glance, this looks like a bug on the Ignite side.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22022) Sql. Json object with nested object creation fails
Pavel Pereslegin created IGNITE-22022:
-
Summary: Sql. Json object with nested object creation fails
Key: IGNITE-22022
URL: https://issues.apache.org/jira/browse/IGNITE-22022
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
{{json_object}} function fails when trying to create object with nested object
{code:java}
assertQuery("select json_object('name': 'Alex', 'address':
json_object('city': 'City 17', 'street': 'Elm'))")
.returns("{\"name\":\"Alex\",\"address\":{\"city\":\"City
17\",\"street\":\"Elm\"}}")
.check();
{code}
{noformat}
Caused by: java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy96.getExpressionList(Unknown Source)
at org.apache.calcite.rel.core.Project.(Project.java:142)
at
org.apache.ignite.internal.sql.engine.rel.IgniteProject.(IgniteProject.java:83)
at SC.apply(Unknown Source)
at
org.apache.ignite.internal.sql.engine.externalize.RelJson$RelFactory.apply(RelJson.java:128)
at
org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.readRel(RelJsonReader.java:140)
at
org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.readRels(RelJsonReader.java:132)
at
org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.read(RelJsonReader.java:123)
at
org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.fromJson(RelJsonReader.java:86)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$relationalTreeFromJsonString$6(ExecutionServiceImpl.java:300)
at
com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
at
java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
at
com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
at
com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
at
com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.relationalTreeFromJsonString(ExecutionServiceImpl.java:298)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.submitFragment(ExecutionServiceImpl.java:833)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.submitFragment(ExecutionServiceImpl.java:514)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:413)
at
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$1(ExecutionServiceImpl.java:262)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:151)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:115)
... 4 more
Caused by: java.lang.reflect.InvocationTargetException
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.ignite.internal.sql.engine.trait.TraitUtils.lambda$changeTraits$0(TraitUtils.java:265)
... 26 more
Caused by: java.lang.NullPointerException: operator
at java.base/java.util.Objects.requireNonNull(Objects.java:246)
at org.apache.calcite.rex.RexCall.(RexCall.java:81)
at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:258)
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:828)
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toRexList(RelJson.java:1027)
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:787)
at
org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:303)
... 28 more
{noformat}
At first glance, this looks like a bug on the Ignite side.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19687) Support default distribution zone reassignment in Catalog
[
https://issues.apache.org/jira/browse/IGNITE-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-19687:
-
Assignee: Pavel Pereslegin
> Support default distribution zone reassignment in Catalog
> -
>
> Key: IGNITE-19687
> URL: https://issues.apache.org/jira/browse/IGNITE-19687
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> *Motivation.*
> We have no reasonable arguments that we need a special distribution zone
> instance. All distribution zones are equals. Thus, conceptually, any zone can
> be used as default one and can be renamed.
> For better UX, we still can require at least one distribution zone, which is
> currently assigned as default zone, must always exists.
> Let's
> * Avoid using any hardcoded zone id or zone name for getting or detecting the
> default distribution zone.
> * Distributed zone manager shouldn't care which zone is default. Catalog will
> be responsible for resolving default zone if it is not specified when table
> is creating.
> * Add a property in Catalog that will store default zone by zone id.
> * Forbid dropping of distribution zone, which is currently marked as default.
> h3. *Implementation notes*
> We need to enhance {{org.apache.ignite.internal.catalog.Catalog#Catalog}}
> with the default zone id, so when {{UpdateEntry#applyUpdate}} will recreate
> Catalog for a SQL command of setting default zone, the new zone id could be
> saved to Catalog state.
> Also tests must be added here like tests for altering zone and checking that
> tables will use the new default zone, test validation for dropping of
> distribution zone, which is currently marked as default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19274) Sql. Jdbc client. Support TIMESTAMP WITH LOCAL TIME ZONE type
[
https://issues.apache.org/jira/browse/IGNITE-19274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19274:
--
Fix Version/s: 3.0.0-beta2
> Sql. Jdbc client. Support TIMESTAMP WITH LOCAL TIME ZONE type
> --
>
> Key: IGNITE-19274
> URL: https://issues.apache.org/jira/browse/IGNITE-19274
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> The {{TIMESTAMP WITH LOCAL TIME ZONE}} data type is a variant of
> {{TIMESTAMP}} that includes a time zone offset in its value. Data stored in
> the database is normalized to the database time zone (UTC) and time zone
> offset is not stored as part of the column data. When the data is retrieved,
> it to be returned in the user's local session time zone.
> i.e:
> {noformat}
> CREATE TABLE timestamp(ts TIMESTAMP, t_tz TIMESTAMP WITH LOCAL TIME ZONE);
> SET TIME ZONE 'tz1';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL
> TIME ZONE '2011-01-01 01:01:01');
> SET TIME ZONE 'tz2';
> INSERT INTO timestamp VALUES ('2011-01-01 01:01:01', TIMESTAMP WITH LOCAL
> TIME ZONE '2011-01-01 01:01:01');
> ...
> select * from timestamp;{noformat}
> returned rows need to be different in case of different tz1 and tz2 offsets
> but they are equals for now. Also returned representation need to be present
> in user session time zone.
> h5. Update from 26.02.2024:
> Definition of done for this task:
> * Client time zone is passed to server (check other database implementations
> to decide how and when to pass it).
> * Data of type "TIMESTAMP With LOCAL TIME ZONE" can be written/read correctly
> using the dynamic parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21916) Cover SQL T828 (JSON_QUERY) feature by tests
[ https://issues.apache.org/jira/browse/IGNITE-21916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835435#comment-17835435 ] Pavel Pereslegin commented on IGNITE-21916: --- Calcite doesn't support JSON_TABLE, that's why we cannot fully support T821 "Basic SQL/JSON query operators", but it seems that other functions are supported (JSON_VALUE, JSON_QUERY, JSON_EXISTS and json predicate) > Cover SQL T828 (JSON_QUERY) feature by tests > > > Key: IGNITE-21916 > URL: https://issues.apache.org/jira/browse/IGNITE-21916 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > We don't have at all any tests for T828 (JSON_QUERY) SQL feature. > Let's cover it and create tickets to fix them in case find any issues related > to covered area -- This message was sent by Atlassian Jira (v8.20.10#820010)
