[jira] [Comment Edited] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884281#comment-17884281
]
Pavel Pereslegin edited comment on IGNITE-21793 at 9/24/24 3:36 PM:
The behavior of the embedded client is inconsistent (and looks incorrect) with
the thin client when trying to read a narrower integer type from tuple.
For example, when we have table with bigint column val.
{code:sql}
create table test_int (id bigint primary key, val bigint not null)
{code}
Getting existing row from view
{code:java}
tuple = kvVIew.get(null, key);
{code}
the next
{code:java}
tuple.intValue("VAL")
{code}
in thin client produces
{noformat}
ClassCastException: Column with name 'VAL' has type INT64 but INT32 was
requested
{noformat}
but does not produces any errors in embedded client.
(need to check the same case with record view also)
Full reproducer
{code:java}
sql("create table test_int (id bigint primary key, val bigint)");
KeyValueView kvVIew =
client.tables().table("test_int").keyValueView();
KeyValueView kvVIewEmbedded =
CLUSTER.aliveNode().tables().table("test_int").keyValueView();
Tuple key = Tuple.create().set("id", 1L);
Tuple val = Tuple.create().set("val", 1L);
kvVIew.put(null, key, val);
Tuple thinReturnedVal = kvVIew.get(null, key);
Tuple embeddedReturnedVal = kvVIewEmbedded.get(null, key);
assertEquals(1, embeddedReturnedVal.longValue(0));
assertEquals(1, thinReturnedVal.longValue(0));
// The following statement should fail, but does not fail.
assertEquals(1, embeddedReturnedVal.intValue("VAL"));
// The following statement fails with ClassCastException.
assertEquals(1, thinReturnedVal.intValue("VAL"));
{code}
was (Author: xtern):
The behavior of the embedded client is inconsistent (and looks incorrect) with
the thin client when trying to read a narrower integer type from tuple.
For example, when we have table with bigint column val.
{code:sql}
create table test_int (id bigint primary key, val bigint not null)
{code}
Getting existing row from view
{code:java}
tuple = kvVIew.get(null, key);
{code}
the next
{code:java}
tuple.intValue("VAL")
{code}
produces
{noformat}
ClassCastException: Column with name 'VAL' has type INT64 but INT32 was
requested
{noformat}
on thin client and does not produces errors in embedded client.
(need to check the same case with record view also)
Full reproducer
{code:java}
sql("create table test_int (id bigint primary key, val bigint)");
KeyValueView kvVIew =
client.tables().table("test_int").keyValueView();
KeyValueView kvVIewEmbedded =
CLUSTER.aliveNode().tables().table("test_int").keyValueView();
Tuple key = Tuple.create().set("id", 1L);
Tuple val = Tuple.create().set("val", 1L);
kvVIew.put(null, key, val);
Tuple thinReturnedVal = kvVIew.get(null, key);
Tuple embeddedReturnedVal = kvVIewEmbedded.get(null, key);
assertEquals(1, embeddedReturnedVal.longValue(0));
assertEquals(1, thinReturnedVal.longValue(0));
// The following statement should fail, but does not fail.
assertEquals(1, embeddedReturnedVal.intValue("VAL"));
// The following statement fails with ClassCastException.
assertEquals(1, thinReturnedVal.intValue("VAL"));
{code}
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884281#comment-17884281
]
Pavel Pereslegin edited comment on IGNITE-21793 at 9/24/24 3:35 PM:
The behavior of the embedded client is inconsistent (and looks incorrect) with
the thin client when trying to read a narrower integer type from tuple.
For example, when we have table with bigint column val.
{code:sql}
create table test_int (id bigint primary key, val bigint not null)
{code}
Getting existing row from view
{code:java}
tuple = kvVIew.get(null, key);
{code}
the next
{code:java}
tuple.intValue("VAL")
{code}
produces
{noformat}
ClassCastException: Column with name 'VAL' has type INT64 but INT32 was
requested
{noformat}
on thin client and does not produces errors in embedded client.
(need to check the same case with record view also)
Full reproducer
{code:java}
sql("create table test_int (id bigint primary key, val bigint)");
KeyValueView kvVIew =
client.tables().table("test_int").keyValueView();
KeyValueView kvVIewEmbedded =
CLUSTER.aliveNode().tables().table("test_int").keyValueView();
Tuple key = Tuple.create().set("id", 1L);
Tuple val = Tuple.create().set("val", 1L);
kvVIew.put(null, key, val);
Tuple thinReturnedVal = kvVIew.get(null, key);
Tuple embeddedReturnedVal = kvVIewEmbedded.get(null, key);
assertEquals(1, embeddedReturnedVal.longValue(0));
assertEquals(1, thinReturnedVal.longValue(0));
// The following statement should fail, but does not fail.
assertEquals(1, embeddedReturnedVal.intValue("VAL"));
// The following statement fails with ClassCastException.
assertEquals(1, thinReturnedVal.intValue("VAL"));
{code}
was (Author: xtern):
The behavior of the embedded client is inconsistent (and looks incorrect) with
the thin client when trying to read a narrower integer type.
For example, when we have table with bigint column val.
{code:sql}
create table test_int (id bigint primary key, val bigint not null)
{code}
Getting existing row from view
{code:java}
tuple = kvVIew.get(null, key);
{code}
the next
{code:java}
tuple.intValue("VAL")
{code}
produces
{noformat}
ClassCastException: Column with name 'VAL' has type INT64 but INT32 was
requested
{noformat}
on thin client and does not produces errors in embedded client.
(need to check the same case with record view also)
Full reproducer
{code:java}
sql("create table test_int (id bigint primary key, val bigint)");
KeyValueView kvVIew =
client.tables().table("test_int").keyValueView();
KeyValueView kvVIewEmbedded =
CLUSTER.aliveNode().tables().table("test_int").keyValueView();
Tuple key = Tuple.create().set("id", 1L);
Tuple val = Tuple.create().set("val", 1L);
kvVIew.put(null, key, val);
Tuple thinReturnedVal = kvVIew.get(null, key);
Tuple embeddedReturnedVal = kvVIewEmbedded.get(null, key);
assertEquals(1, embeddedReturnedVal.longValue(0));
assertEquals(1, thinReturnedVal.longValue(0));
// The following statement should fail, but does not fail.
assertEquals(1, embeddedReturnedVal.intValue("VAL"));
// The following statement fails with ClassCastException.
assertEquals(1, thinReturnedVal.intValue("VAL"));
{code}
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884306#comment-17884306
]
Pavel Pereslegin edited comment on IGNITE-21793 at 9/24/24 2:46 PM:
The following code
{code:java}
sql("create table test_x(id int primary key, val int)");
// RecordView recView =
CLUSTER.aliveNode().tables().table("test_x").recordView();
// RecordView recView = client.table("test_x").recordView();
recView.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
in embedded client throws SchemaMismatchException: Key tuple contains extra
columns: [VAL]
but works fine in thin client.
Looks like thin client must also throw exception in such case.
The same case is actual for key-value binary view
{code:java}
sql("create table test_x(id int primary key, val int)");
KeyValueView view =
client.tables().table("test_x").keyValueView();
// thin client must also throw an exception, like embedded does
view.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
was (Author: xtern):
The following code
{code:java}
sql("create table test_x(id int primary key, val int)");
// RecordView recView =
CLUSTER.aliveNode().tables().table("test_x").recordView();
// RecordView recView = client.table("test_x").recordView();
recView.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
in embedded client throws SchemaMismatchException: Key tuple contains extra
columns: [VAL]
but works fine in thin client.
Looks like thin client must also throw exception in such case.
The same case is actual for key-value binary view
{code:java}
sql("create table test_x(id int primary key, val int)");
KeyValueView view =
client.tables().table("test_x").keyValueView();
view.get(null, Tuple.create().set("id", 1).set("val", 1)); // does not
produce exception in thin client
{code}
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884306#comment-17884306
]
Pavel Pereslegin edited comment on IGNITE-21793 at 9/24/24 2:46 PM:
The following code
{code:java}
sql("create table test_x(id int primary key, val int)");
// RecordView recView =
CLUSTER.aliveNode().tables().table("test_x").recordView();
// RecordView recView = client.table("test_x").recordView();
recView.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
in embedded client throws SchemaMismatchException: Key tuple contains extra
columns: [VAL]
but works fine in thin client.
Looks like thin client must also throw exception in such case.
The same case is also actual for key-value binary view
{code:java}
sql("create table test_x(id int primary key, val int)");
KeyValueView view =
client.tables().table("test_x").keyValueView();
// thin client must also throw an exception, like embedded does
view.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
was (Author: xtern):
The following code
{code:java}
sql("create table test_x(id int primary key, val int)");
// RecordView recView =
CLUSTER.aliveNode().tables().table("test_x").recordView();
// RecordView recView = client.table("test_x").recordView();
recView.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
in embedded client throws SchemaMismatchException: Key tuple contains extra
columns: [VAL]
but works fine in thin client.
Looks like thin client must also throw exception in such case.
The same case is actual for key-value binary view
{code:java}
sql("create table test_x(id int primary key, val int)");
KeyValueView view =
client.tables().table("test_x").keyValueView();
// thin client must also throw an exception, like embedded does
view.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884306#comment-17884306
]
Pavel Pereslegin commented on IGNITE-21793:
---
The following code
{code:java}
sql("create table test_x(id int primary key, val int)");
// RecordView recView =
CLUSTER.aliveNode().tables().table("test_x").recordView();
// RecordView recView = client.table("test_x").recordView();
recView.get(null, Tuple.create().set("id", 1).set("val", 1));
{code}
in embedded client throws SchemaMismatchException: Key tuple contains extra
columns: [VAL]
but works fine in thin client.
Looks like thin client must also throw exception in such case.
The same case is actual for key-value binary view
{code:java}
sql("create table test_x(id int primary key, val int)");
KeyValueView view =
client.tables().table("test_x").keyValueView();
view.get(null, Tuple.create().set("id", 1).set("val", 1)); // does not
produce exception in thin client
{code}
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884281#comment-17884281
]
Pavel Pereslegin edited comment on IGNITE-21793 at 9/24/24 1:42 PM:
The behavior of the embedded client is inconsistent (and looks incorrect) with
the thin client when trying to read a narrower integer type.
For example, when we have table with bigint column val.
{code:sql}
create table test_int (id bigint primary key, val bigint not null)
{code}
Getting existing row from view
{code:java}
tuple = kvVIew.get(null, key);
{code}
the next
{code:java}
tuple.intValue("VAL")
{code}
produces
{noformat}
ClassCastException: Column with name 'VAL' has type INT64 but INT32 was
requested
{noformat}
on thin client and does not produces errors in embedded client.
(need to check the same case with record view also)
Full reproducer
{code:java}
sql("create table test_int (id bigint primary key, val bigint)");
KeyValueView kvVIew =
client.tables().table("test_int").keyValueView();
KeyValueView kvVIewEmbedded =
CLUSTER.aliveNode().tables().table("test_int").keyValueView();
Tuple key = Tuple.create().set("id", 1L);
Tuple val = Tuple.create().set("val", 1L);
kvVIew.put(null, key, val);
Tuple thinReturnedVal = kvVIew.get(null, key);
Tuple embeddedReturnedVal = kvVIewEmbedded.get(null, key);
assertEquals(1, embeddedReturnedVal.longValue(0));
assertEquals(1, thinReturnedVal.longValue(0));
// The following statement should fail, but does not fail.
assertEquals(1, embeddedReturnedVal.intValue("VAL"));
// The following statement fails with ClassCastException.
assertEquals(1, thinReturnedVal.intValue("VAL"));
{code}
was (Author: xtern):
The behavior of the embedded client is inconsistent (and looks incorrect) with
the thin client when trying to read a narrower integer type.
For example, when we have table with bigint column val.
{code:sql}
create table test_int (id bigint primary key, val bigint not null)
{code}
Getting existing row from view
{code:java}
tuple = kvVIew.get(null, key);
{code}
the next
{code:java}
tuple.intValue("VAL")
{code}
produces
{noformat}
ClassCastException: Column with name 'VAL' has type INT64 but INT32 was
requested
{noformat}
on thin client and does not produces errors in embedded client.
Full reproducer
{code:java}
sql("create table test_int (id bigint primary key, val bigint)");
KeyValueView kvVIew =
client.tables().table("test_int").keyValueView();
KeyValueView kvVIewEmbedded =
CLUSTER.aliveNode().tables().table("test_int").keyValueView();
Tuple key = Tuple.create().set("id", 1L);
Tuple val = Tuple.create().set("val", 1L);
kvVIew.put(null, key, val);
Tuple thinReturnedVal = kvVIew.get(null, key);
Tuple embeddedReturnedVal = kvVIewEmbedded.get(null, key);
assertEquals(1, embeddedReturnedVal.longValue(0));
assertEquals(1, thinReturnedVal.longValue(0));
// The following statement should fail, but does not fail.
assertEquals(1, embeddedReturnedVal.intValue("VAL"));
// The following statement fails with ClassCastException.
assertEquals(1, thinReturnedVal.intValue("VAL"));
{code}
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884281#comment-17884281
]
Pavel Pereslegin commented on IGNITE-21793:
---
The behavior of the embedded client is inconsistent (and looks incorrect) with
the thin client when trying to read a narrower integer type.
For example, when we have table with bigint column val.
{code:sql}
create table test_int (id bigint primary key, val bigint not null)
{code}
Getting existing row from view
{code:java}
tuple = kvVIew.get(null, key);
{code}
the next
{code:java}
tuple.intValue("VAL")
{code}
produces
{noformat}
ClassCastException: Column with name 'VAL' has type INT64 but INT32 was
requested
{noformat}
on thin client and does not produces errors in embedded client.
Full reproducer
{code:java}
sql("create table test_int (id bigint primary key, val bigint)");
KeyValueView kvVIew =
client.tables().table("test_int").keyValueView();
KeyValueView kvVIewEmbedded =
CLUSTER.aliveNode().tables().table("test_int").keyValueView();
Tuple key = Tuple.create().set("id", 1L);
Tuple val = Tuple.create().set("val", 1L);
kvVIew.put(null, key, val);
Tuple thinReturnedVal = kvVIew.get(null, key);
Tuple embeddedReturnedVal = kvVIewEmbedded.get(null, key);
assertEquals(1, embeddedReturnedVal.longValue(0));
assertEquals(1, thinReturnedVal.longValue(0));
// The following statement should fail, but does not fail.
assertEquals(1, embeddedReturnedVal.intValue("VAL"));
// The following statement fails with ClassCastException.
assertEquals(1, thinReturnedVal.intValue("VAL"));
{code}
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21793) Fix inconsistencies in table view APIs
[
https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883824#comment-17883824
]
Pavel Pereslegin commented on IGNITE-21793:
---
*getOrDefault* (in ClientKeyValueView) for simple type mapped null-value must
return default value instead of exception.
For example, we have a table with primary key "id long" and a single column
"val long"
And this table contains single row with id = 1 and val = null
{code:java}
KeyValueView tbl = view();
long val = tbl.getOrDefault(null, 1L, Long.MAX_VALUE));
{code}
Embedded client gets {{Long.MAX_VALUE}}
Thin client throws UnexpectedNullValueException
> Fix inconsistencies in table view APIs
> --
>
> Key: IGNITE-21793
> URL: https://issues.apache.org/jira/browse/IGNITE-21793
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Alexey Scherbakov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
>
> # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is
> to ensure null safety. It should not accept or nulls (*getNullable* methods
> exist to deal with nulls)
> # *getNullable* family of methods throws exceptions from tuple-based views
> (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work
> same as equivalent getters to ensure view equivalence.
> # *getAndReplaceAsync* has nullable key and value, but actual implementations
> (client and embedded) disallow nulls.
> # *getNullableAndPut* throws *MarshallerException* when value is null, unlike
> *getAndPut* which correctly throws *NullPointerException*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 2:45 PM:
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from the original optimal plan
(TableModify.soruceExpressionList=[null]).
2. Rewrite the original AST so that sourceExpressionList contains a reference
to the desired column from selectList (see linked PR).
Look like this works well for UPDATE statement, but not working for MERGE in
some cases.
For example for the case in the description originally we have in
sourceExpressionList
{noformat}
0 = {SqlBasicCall@23387} "(SELECT `VAL`\nFROM `T1`\nWHERE `ID` = -42) AS
`EXPR$0`"
{noformat}
sourceSelect
{noformat}
SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`
{noformat}
After rewrite expressionList
{code}
0 = {SqlIdentifier} "EXPR$0"
{code}
sourceSelect
{code}
SELECT `ID`, `VAL`, `EXPR$0`
FROM (SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`)
{code}
Without wrapping into subquery validator cannot resolve what `EXPR$0`is (need
to investigate).
That's working for UPDATE but not for merge.
In the attached PR we just keeping original behavior of MERGE.
And for the following example
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("CREATE TABLE t1(ID INT PRIMARY KEY, B INT)");
sql("INSERT INTO t0 VALUES (1, 0), (2, 0)");
sql("INSERT INTO t1 VALUES (1, -100), (3, 3)");
// sub-query returns single row.
sql("MERGE INTO t0 USING t1 ON t0.id = t1.id "
+ "WHEN MATCHED THEN UPDATE SET A = (SELECT B FROM t1 WHERE id
= 2)");
{code}
sourceSelect of merge looks like this:
{code:sql}
SELECT `T0`.`ID`, `T0`.`A`, (SELECT `B`
FROM `T1`
WHERE `ID` > ?) AS `EXPR$0`
FROM `T1`
INNER JOIN `T0` ON `T0`.`ID` = `T1`.`ID`
{code}
But if we change column B to BIGINT example fails with
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 0,
column 0: Column 'EXPR$0' not found in any table
at
java.base@11.0.17/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
app//org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5643)
at
app//org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.newValidationError(IgniteSqlValidator.java:275)
at
app//org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:293)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6852)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:7023)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
*UPDATE*
The following case (looks related) gives the *physical* plan with *logical
nodes*
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
sql("UPDATE t0 SET a = a + (SELECT 1)");
{code}
look at TableModify.sourceExpressionList
{noformat}
Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
network=240002.0], id = 246
ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
io=1.0, network=240001.0], id = 245
Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
network=240001.0], id = 244
TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
LogicalValues(tuples=[[{ 1 }]])
}))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
network=21.0], id = 243
Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
io=0.0, network=20.0], id = 242
Exchange(distribution=[affinity[tableId=9, zoneId=9][0]]): rowcount =
1.0, cumulative cost = IgniteCost [rowCount=40001.0, cpu=70001.0,
memory=4.0, io=0.0, network=20.0], id = 241
NestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=30001.0, cpu=60001.0, memory=4.0, io=0.0, network=8.0], id = 240
Exchange(distribution=[single]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0,
network=8.0], id = 238
TableScan(table=[[PUBLIC, T0]], tableId=[9],
requiredColumns=[{0, 1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 237
Values(tuples=[[{ 1 }]]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 239
{noformat}
that cannot be deserialized
{noformat}
Caused by: java.lang.IllegalStateException: Unknown or unexpected operator:
name: $SCALAR_QUERY, kind: SCALAR_QUERY, syntax: INTERNAL
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toOp(RelJson.java:944)
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 1:20 PM:
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
2. Rewrite the original AST so that sourceExpressionList contains a reference
to the desired column from selectList (see linked PR).
Look like this works well for UPDATE statement, but not working for MERGE in
some cases.
For example for the case in the description originally we have in
sourceExpressionList
{noformat}
0 = {SqlBasicCall@23387} "(SELECT `VAL`\nFROM `T1`\nWHERE `ID` = -42) AS
`EXPR$0`"
{noformat}
sourceSelect
{noformat}
SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`
{noformat}
After rewrite expressionList
{code}
0 = {SqlIdentifier} "EXPR$0"
{code}
sourceSelect
{code}
SELECT `ID`, `VAL`, `EXPR$0`
FROM (SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`)
{code}
Without wrapping into subquery validator cannot resolve what `EXPR$0`is (need
to investigate).
That's working for UPDATE but not for merge.
In the attached PR we just keeping original behavior of MERGE.
And for the following example
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("CREATE TABLE t1(ID INT PRIMARY KEY, B INT)");
sql("INSERT INTO t0 VALUES (1, 0), (2, 0)");
sql("INSERT INTO t1 VALUES (1, -100), (3, 3)");
// sub-query returns single row.
sql("MERGE INTO t0 USING t1 ON t0.id = t1.id "
+ "WHEN MATCHED THEN UPDATE SET A = (SELECT B FROM t1 WHERE id
= 2)");
{code}
sourceSelect of merge looks like this:
{code:sql}
SELECT `T0`.`ID`, `T0`.`A`, (SELECT `B`
FROM `T1`
WHERE `ID` > ?) AS `EXPR$0`
FROM `T1`
INNER JOIN `T0` ON `T0`.`ID` = `T1`.`ID`
{code}
But if we change column B to BIGINT example fails with
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 0,
column 0: Column 'EXPR$0' not found in any table
at
java.base@11.0.17/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
app//org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5643)
at
app//org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.newValidationError(IgniteSqlValidator.java:275)
at
app//org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:293)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6852)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:7023)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 12:59 PM:
-
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
2. Rewrite the original AST so that sourceExpressionList contains a reference
to the desired column from selectList (see linked PR).
Look like this works well for UPDATE statement, but not working for MERGE in
some cases.
For example for the case in the description originally we have in
sourceExpressionList
{noformat}
0 = {SqlBasicCall@23387} "(SELECT `VAL`\nFROM `T1`\nWHERE `ID` = -42) AS
`EXPR$0`"
{noformat}
sourceSelect
{noformat}
SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`
{noformat}
After rewrite expressionList
{code}
0 = {SqlIdentifier} "EXPR$0"
{code}
sourceSelect
{code}
SELECT `ID`, `VAL`, `EXPR$0`
FROM (SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`)
{code}
Without wrapping into subquery validator cannot resolve what `EXPR$0`is (need
to investigate).
That's working for UPDATE but not for merge.
In the attached PR we just keeping original behavior of MERGE.
And for the following example
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("CREATE TABLE t1(ID INT PRIMARY KEY, B INT)");
sql("INSERT INTO t0 VALUES (1, 0), (2, 0)");
sql("INSERT INTO t1 VALUES (1, -100), (3, 3)");
// sub-query returns single row.
sql("MERGE INTO t0 USING t1 ON t0.id = t1.id "
+ "WHEN MATCHED THEN UPDATE SET A = (SELECT B FROM t1 WHERE id
= 2)");
{code}
sourceSelect of merge looks like this:
{code:sql}
SELECT `T0`.`ID`, `T0`.`A`, (SELECT `B`
FROM `T1`
WHERE `ID` > ?) AS `EXPR$0`
FROM `T1`
INNER JOIN `T0` ON `T0`.`ID` = `T1`.`ID`
{code}
But if we change column B to BIGINT example fails with
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 0,
column 0: Column 'EXPR$0' not found in any table
at
java.base@11.0.17/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
app//org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5643)
at
app//org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.newValidationError(IgniteSqlValidator.java:275)
at
app//org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:293)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6852)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:7023)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.ja
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 12:56 PM:
-
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
2. Rewrite the original AST so that sourceExpressionList contains a reference
to the desired column from selectList (see linked PR).
Look like this works well for UPDATE statement, but not working for MERGE in
some cases.
For example for the case in the description originally we have in
sourceExpressionList
{noformat}
0 = {SqlBasicCall@23387} "(SELECT `VAL`\nFROM `T1`\nWHERE `ID` = -42) AS
`EXPR$0`"
{noformat}
sourceSelect
{noformat}
SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`
{noformat}
After rewrite expressionList
{code}
0 = {SqlIdentifier} "EXPR$0"
{code}
sourceSelect
{code}
SELECT `ID`, `VAL`, `EXPR$0`
FROM (SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`)
{code}
Without wrapping into subquery validator cannot resolve what `EXPR$0`is (need
to investigate).
That's working for UPDATE but not for merge.
In the attached PR we just keeping original behavior of MERGE.
And for the following example
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("CREATE TABLE t1(ID INT PRIMARY KEY, B INT)");
sql("INSERT INTO t0 VALUES (1, 0), (2, 0)");
sql("INSERT INTO t1 VALUES (1, -100), (3, 3)");
// sub-query returns single row.
sql("MERGE INTO t0 USING t1 ON t0.id = t1.id "
+ "WHEN MATCHED THEN UPDATE SET A = (SELECT B FROM t1 WHERE id
= 2)");
{code}
AST for sourceSelect looks as follows:
{code:sql}
SELECT `T0`.`ID`, `T0`.`A`, (SELECT `B`
FROM `T1`
WHERE `ID` > ?) AS `EXPR$0`
FROM `T1`
INNER JOIN `T0` ON `T0`.`ID` = `T1`.`ID`
{code}
But if we change column B to BIGINT example fails with
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 0,
column 0: Column 'EXPR$0' not found in any table
at
java.base@11.0.17/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
app//org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5643)
at
app//org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.newValidationError(IgniteSqlValidator.java:275)
at
app//org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:293)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6852)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:7023)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.ja
[jira] [Assigned] (IGNITE-16707) Unify table API integration tests
[ https://issues.apache.org/jira/browse/IGNITE-16707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-16707: - Assignee: Pavel Pereslegin > Unify table API integration tests > - > > Key: IGNITE-16707 > URL: https://issues.apache.org/jira/browse/IGNITE-16707 > Project: Ignite > Issue Type: Test > Components: sql >Reporter: Andrey Mashenkov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3, tech-debt > > Ignite provides KeyValueView and RecordView (+binary variants) APIs. > These views have implementations on server side and on client side, see > ignite-table and ignite-client modules. > All the views have same guaranties as on server as on client, but we have > different set of test for them. > Let's get rid of duplicates and made a single parametrized test class for > each view, where we will check the guaranties against server and client > implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
*UPDATE*
The following case looks related also
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
sql("UPDATE t0 SET a = a + (SELECT 1)");
{code}
gives the phycial plan with *logical nodes*
{noformat}
Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
network=240002.0], id = 252
ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
io=1.0, network=240001.0], id = 251
Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
network=240001.0], id = 250
TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
LogicalValues(tuples=[[{ 1 }]])
}))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
network=21.0], id = 249
Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
io=0.0, network=20.0], id = 248
Exchange(distribution=[affinity[tableId=9, zoneId=9][0]]): rowcount =
1.0, cumulative cost = IgniteCost [rowCount=40001.0, cpu=70001.0,
memory=4.0, io=0.0, network=20.0], id = 247
NestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=30001.0, cpu=60001.0, memory=4.0, io=0.0, network=8.0], id = 246
Exchange(distribution=[single]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0,
network=8.0], id = 244
TableScan(table=[[PUBLIC, T0]], tableId=[9],
requiredColumns=[{0, 1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 243
Values(tuples=[[{ 1 }]]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 245
{noformat}
that cannot be deserialized
{noformat}
Caused by: java.lang.IllegalStateException: Unknown or unexpected operator:
name: $SCALAR_QUERY, kind: SCALAR_QUERY, syntax: INTERNAL
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toOp(RelJson.java:950)
at
org.apache.ignite.internal.sql.
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
*UPDATE*
The following case looks related also
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
sql("UPDATE t0 SET a = a + (SELECT 1)");
{code}
gives the following *phycial* plan with *logical nodes* (look at
TableModify.sourceExpressionList)
{noformat}
Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
network=240002.0], id = 246
ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
io=1.0, network=240001.0], id = 245
Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
network=240001.0], id = 244
TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
LogicalValues(tuples=[[{ 1 }]])
}))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
network=21.0], id = 243
Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
io=0.0, network=20.0], id = 242
Exchange(distribution=[affinity[tableId=9, zoneId=9][0]]): rowcount =
1.0, cumulative cost = IgniteCost [rowCount=40001.0, cpu=70001.0,
memory=4.0, io=0.0, network=20.0], id = 241
NestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=30001.0, cpu=60001.0, memory=4.0, io=0.0, network=8.0], id = 240
Exchange(distribution=[single]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0,
network=8.0], id = 238
TableScan(table=[[PUBLIC, T0]], tableId=[9],
requiredColumns=[{0, 1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 237
Values(tuples=[[{ 1 }]]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 239
{noformat}
that cannot be deserialized
{noformat}
Caused by: java.lang.IllegalStateException: Unknown or unexpected operator:
name: $SCALAR_QUERY, kind: SCALAR_QUERY, syntax: INTERNAL
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toOp(RelJs
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 11:06 AM:
-
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
2. Rewrite the original AST so that sourceExpressionList contains a reference
to the desired column from selectList (see linked PR).
Look like this works well for UPDATE statement, but not working for MERGE in
some cases.
For example for the case in the description originally we have in
sourceExpressionList
{noformat}
0 = {SqlBasicCall@23387} "(SELECT `VAL`\nFROM `T1`\nWHERE `ID` = -42) AS
`EXPR$0`"
{noformat}
sourceSelect
{noformat}
SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`
{noformat}
After rewrite expressionList
{code}
0 = {SqlIdentifier} "EXPR$0"
{code}
sourceSelect
{code}
SELECT `ID`, `VAL`, `EXPR$0`
FROM (SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`)
{code}
Without wrapping into subquery validator cannot resolve what `EXPR$0`is (need
to investigate).
That's working for UPDATE but not for merge.
A. In the attached PR we just keeping original behavior of MERGE.
The following example works fine
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("CREATE TABLE t1(ID INT PRIMARY KEY, B INT)");
sql("INSERT INTO t0 VALUES (1, 0), (2, 0)");
sql("INSERT INTO t1 VALUES (1, -100), (3, 3)");
// sub-query returns single row.
sql("MERGE INTO t0 USING t1 ON t0.id = t1.id "
+ "WHEN MATCHED THEN UPDATE SET A = (SELECT B FROM t1 WHERE id
= 2)");
{code}
But if we change column B to BIGINT example fails with
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 0,
column 0: Column 'EXPR$0' not found in any table
at
java.base@11.0.17/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
app//org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
at
app//org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5643)
at
app//org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.newValidationError(IgniteSqlValidator.java:275)
at
app//org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:293)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6852)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:7023)
at
app//org.apache.calcite.sql.validate.SqlValidatorImpl$SelectExpander.visit(SqlValidatorImpl.java:7008)
at
app//org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:327)
at
app//org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitCh
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 10:49 AM:
-
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
2. Rewrite the original AST so that sourceExpressionList contains a reference
to the desired column from selectList (see linked PR).
Look like this works well for UPDATE statement, but not working for MERGE in
some cases.
For example for the case in the description originally we have in
sourceExpressionList
{noformat}
0 = {SqlBasicCall@23387} "(SELECT `VAL`\nFROM `T1`\nWHERE `ID` = -42) AS
`EXPR$0`"
{noformat}
sourceSelect
{noformat}
SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`
{noformat}
After rewrite expressionList
{code}
0 = {SqlIdentifier} "EXPR$0"
{code}
sourceSelect
{code}
SELECT `ID`, `VAL`, `EXPR$0`
FROM (SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`)
{code}
Without wrap into subquery validator cannot resolve what `EXPR$0`is.
was (Author: xtern):
The root cause of problem with assertion and possible fix is described in the
calcite issue comment.
{panel:title=issue description}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 10:55 AM:
-
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
2. Rewrite the original AST so that sourceExpressionList contains a reference
to the desired column from selectList (see linked PR).
Look like this works well for UPDATE statement, but not working for MERGE in
some cases.
For example for the case in the description originally we have in
sourceExpressionList
{noformat}
0 = {SqlBasicCall@23387} "(SELECT `VAL`\nFROM `T1`\nWHERE `ID` = -42) AS
`EXPR$0`"
{noformat}
sourceSelect
{noformat}
SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`
{noformat}
After rewrite expressionList
{code}
0 = {SqlIdentifier} "EXPR$0"
{code}
sourceSelect
{code}
SELECT `ID`, `VAL`, `EXPR$0`
FROM (SELECT `T0`.`ID`, `T0`.`VAL`, (SELECT `VAL`
FROM `T1`
WHERE `ID` = -42) AS `EXPR$0`
FROM `T0`)
{code}
Without wrapping into subquery validator cannot resolve what `EXPR$0`is (need
to investigate).
That's working for UPDATE but not for merge.
A. In the attached PR we just keeping original behavior of MERGE.
The following example works fine
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("CREATE TABLE t1(ID INT PRIMARY KEY, B INT)");
sql("INSERT INTO t0 VALUES (1, 0), (2, 0)");
sql("INSERT INTO t1 VALUES (1, -100), (3, 3)");
// sub-query returns single row.
sql("MERGE INTO t0 USING t1 ON t0.id = t1.id "
+ "WHEN MATCHED THEN UPDATE SET A = (SELECT B FROM t1 WHERE id
= 2)");
{code}
But if we change column B to BIGINT example fails with
{noformat}
{noformat}
was (Author: xtern):
The root cause of problem with assertion and possible fix is described in the
calcite issue
[comment|https://issues.apache.org/jira/browse/CALCITE-6570?focusedCommentId=17881589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17881589].
{panel}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.source
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
*UPDATE*
The following case looks related also
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
sql("UPDATE t0 SET a = a + (SELECT 1)");
{code}
gives the *physical* plan with *logical nodes* (look at
TableModify.sourceExpressionList)
{noformat}
Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
network=240002.0], id = 246
ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
io=1.0, network=240001.0], id = 245
Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
network=240001.0], id = 244
TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
LogicalValues(tuples=[[{ 1 }]])
}))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
network=21.0], id = 243
Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
io=0.0, network=20.0], id = 242
Exchange(distribution=[affinity[tableId=9, zoneId=9][0]]): rowcount =
1.0, cumulative cost = IgniteCost [rowCount=40001.0, cpu=70001.0,
memory=4.0, io=0.0, network=20.0], id = 241
NestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=30001.0, cpu=60001.0, memory=4.0, io=0.0, network=8.0], id = 240
Exchange(distribution=[single]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0,
network=8.0], id = 238
TableScan(table=[[PUBLIC, T0]], tableId=[9],
requiredColumns=[{0, 1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 237
Values(tuples=[[{ 1 }]]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 239
{noformat}
that cannot be deserialized
{noformat}
Caused by: java.lang.IllegalStateException: Unknown or unexpected operator:
name: $SCALAR_QUERY, kind: SCALAR_QUERY, syntax: INTERNAL
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toOp(RelJson.java:9
[jira] [Comment Edited] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin edited comment on IGNITE-23183 at 9/19/24 10:31 AM:
-
The root cause of problem with assertion and possible fix is described in the
calcite issue comment.
{panel:title=issue description}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
{panel}
The possible solution - add SCALAR_QUERY to {{sourceExpressionList}} as well.
This works fine for AI3 until we look at the physical plan, the plan contains
an original SCALAR_QUERY in TableModify sourceExpressionList, and we can't
execute such a plan because we can't serialize/deserialize it properly.
Note: with deprecated SqlRelConverter.Config.withExpand(true) this
scalar-subquery will be rewritten and all works fine. But we can't enable it
because some functions stop working when this setting is enabled (I think you
can read about this in the documentation)..
*Therefore, the correct solution would be to rewrite the subquery in
TableModify.sourceExpression on the CALCITE side (in CALCITE-6570).*
Alternative ways and why they don't work:
1. Merge current patch (CALCITE-6570) to calcite and nullify
sourceExpressionList in physical TableModify node on AI3 side.
We don't use sourceExpressionList after planning, but we can't nullify this
list easily.
First parent TableModify has some checks that doesn't allow just set null to
list.
Secondly, after "nullification" plan will differ from original optimal plan
(TableModify.soruceExpressionList=[null]).
was (Author: xtern):
The root cause of problem with assertion and possible fix is described in the
calcite issue comment.
{panel:title=issue description}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
As a solution I added SCALAR_QUERY to sourceExpressionList as well.
{panel}
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
> sql("UPDATE t0 set val = (select id::BIGINT from t0)");
> {code}
> fails with
> {noformat}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
> at
> org.apache.ignite
[jira] [Commented] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882961#comment-17882961
]
Pavel Pereslegin commented on IGNITE-23183:
---
The root cause of problem with assertion and possible fix is described in the
calcite issue comment.
{panel:title=issue description}
During validation, when registering subqueries, we wrap the sub-query in a
SCALAR_QUERY call in selectList (sqlUpdate.getSourceSelect().getSelectList()).
But after that, TypeCoersion tries to coerce types for expressions in
sourceExpressionList (see TypeCoersionImpl.coerceSourceRowType()), but it
contains SqlSelect instead of SCALAR_QUERY call.
As a solution I added SCALAR_QUERY to sourceExpressionList as well.
{panel}
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
> sql("UPDATE t0 set val = (select id::BIGINT from t0)");
> {code}
> fails with
> {noformat}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
> {noformat}
> Issue is caused by CALCITE-6570
> *UPDATE*
> The following case looks related also
> {code:java}
> sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
> sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
> sql("UPDATE t0 SET a = a + (SELECT 1)");
> {code}
> gives the *physical* plan with *logical nodes* (look at
> TableModify.sourceExpressionList)
> {noformat}
> Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost
> = IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
> network=240002.0], id = 246
> ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
> io=1.0, network=240001.0], id = 245
> Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
> network=240001.0], id = 244
> TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
> updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
> LogicalValues(tuples=[[{ 1 }]])
> }))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
> network=21.0], id = 243
> Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
> cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
>
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
*UPDATE*
The following case looks related also
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
sql("UPDATE t0 SET a = a + (SELECT 1)");
{code}
gives the phycial plan with *logical nodes* (look at
TableModify.sourceExpressionList)
{noformat}
Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
network=240002.0], id = 246
ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
io=1.0, network=240001.0], id = 245
Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
network=240001.0], id = 244
TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
LogicalValues(tuples=[[{ 1 }]])
}))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
network=21.0], id = 243
Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
io=0.0, network=20.0], id = 242
Exchange(distribution=[affinity[tableId=9, zoneId=9][0]]): rowcount =
1.0, cumulative cost = IgniteCost [rowCount=40001.0, cpu=70001.0,
memory=4.0, io=0.0, network=20.0], id = 241
NestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=30001.0, cpu=60001.0, memory=4.0, io=0.0, network=8.0], id = 240
Exchange(distribution=[single]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0,
network=8.0], id = 238
TableScan(table=[[PUBLIC, T0]], tableId=[9],
requiredColumns=[{0, 1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 237
Values(tuples=[[{ 1 }]]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 239
{noformat}
that cannot be deserialized
{noformat}
Caused by: java.lang.IllegalStateException: Unknown or unexpected operator:
name: $SCALAR_QUERY, kind: SCALAR_QUERY, syntax: INTERNAL
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toOp(RelJson.java:944)
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
The following case looks related also
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
sql("UPDATE t0 SET a = a + (SELECT 1)");
{code}
gives the phycial plan with *logical nodes*
{noformat}
Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
network=240002.0], id = 252
ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
io=1.0, network=240001.0], id = 251
Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
network=240001.0], id = 250
TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
LogicalValues(tuples=[[{ 1 }]])
}))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
network=21.0], id = 249
Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
io=0.0, network=20.0], id = 248
Exchange(distribution=[affinity[tableId=9, zoneId=9][0]]): rowcount =
1.0, cumulative cost = IgniteCost [rowCount=40001.0, cpu=70001.0,
memory=4.0, io=0.0, network=20.0], id = 247
NestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=30001.0, cpu=60001.0, memory=4.0, io=0.0, network=8.0], id = 246
Exchange(distribution=[single]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0,
network=8.0], id = 244
TableScan(table=[[PUBLIC, T0]], tableId=[9],
requiredColumns=[{0, 1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 243
Values(tuples=[[{ 1 }]]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 245
{noformat}
that cannot be deserialized
{noformat}
Caused by: java.lang.IllegalStateException: Unknown or unexpected operator:
name: $SCALAR_QUERY, kind: SCALAR_QUERY, syntax: INTERNAL
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toOp(RelJson.java:950)
at
org.apache.ignite.internal.sql.engine.ext
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
The following case looks related also
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, A INT)");
sql("INSERT INTO t0 VALUES (1, 1), (2, 2)");
sql("UPDATE t0 SET a = a + (SELECT 1)");
{code}
gives the plan with *logical nodes*
{noformat}
Project(ROWCOUNT=[CAST($0):BIGINT NOT NULL]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=70004.0, cpu=14.0, memory=11.0, io=2.0,
network=240002.0], id = 252
ColocatedHashAggregate(group=[{}], agg#0=[$SUM0($0)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=70002.0, cpu=12.0, memory=10.0,
io=1.0, network=240001.0], id = 251
Exchange(distribution=[single]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=60002.0, cpu=90002.0, memory=5.0, io=1.0,
network=240001.0], id = 250
TableModify(table=[[PUBLIC, T0]], operation=[UPDATE],
updateColumnList=[[A]], sourceExpressionList=[[+($1, $SCALAR_QUERY({
LogicalValues(tuples=[[{ 1 }]])
}))]], flattened=[false], tableId=[9]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=50002.0, cpu=80002.0, memory=5.0, io=1.0,
network=21.0], id = 249
Project(ID=[$0], A=[$1], EXPR$2=[+($1, $2)]): rowcount = 1.0,
cumulative cost = IgniteCost [rowCount=50001.0, cpu=80001.0, memory=4.0,
io=0.0, network=20.0], id = 248
Exchange(distribution=[affinity[tableId=9, zoneId=9][0]]): rowcount =
1.0, cumulative cost = IgniteCost [rowCount=40001.0, cpu=70001.0,
memory=4.0, io=0.0, network=20.0], id = 247
NestedLoopJoin(condition=[true], joinType=[left],
variablesSet=[[]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=30001.0, cpu=60001.0, memory=4.0, io=0.0, network=8.0], id = 246
Exchange(distribution=[single]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0,
network=8.0], id = 244
TableScan(table=[[PUBLIC, T0]], tableId=[9],
requiredColumns=[{0, 1}]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 243
Values(tuples=[[{ 1 }]]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 245
{noformat}
and cannot be deserialized
{noformat}
Caused by: java.lang.IllegalStateException: Unknown or unexpected operator:
name: $SCALAR_QUERY, kind: SCALAR_QUERY, syntax: INTERNAL
at
org.apache.ignite.internal.sql.engine.externalize.RelJson.toOp(RelJson.java:950)
at
org.apache.ignite.internal.sql.engine.externalize.
[jira] [Updated] (IGNITE-20835) Sql. Update statements incorrectly use scalar subqueries in target columns
[
https://issues.apache.org/jira/browse/IGNITE-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20835:
--
Description:
Update statements incorrectly use scalar subqueries in target columns, the
issues stems from the fact that scalar subquery in UPDATE are not wrapped in
`SINGLE_VAL` aggregate.
Examples:
{code:java}
@Test
public void ddml2() {
sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
INTEGER);");
sql("INSERT INTO vals VALUES (1, 0);");
sql("INSERT INTO vals VALUES (2, 0);");
sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
// works
sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
other_vals WHERE id = 1));");
// works
sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
WHERE id = 1");
// Should fail, because a subquery returns more than 1 result.
sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE id
>= 2");
}
UPDATEs in MERGE statement are also affect by this issue:
{code:java}
@Test
public void ddml2_1() {
sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
INTEGER);");
sql("INSERT INTO vals VALUES (1, 0);");
sql("INSERT INTO vals VALUES (2, 0);");
sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
// works
sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
other_vals WHERE id = 1));");
// Fails with PK unique constraint is violated
sql("MERGE INTO vals USING other_vals ON vals.id = other_vals.id "
+ "WHEN MATCHED THEN UPDATE SET val = (SELECT other_val FROM
other_vals WHERE id > 1) "
+ "WHEN NOT MATCHED THEN INSERT (id, val) VALUES (100, -1)");
}
{code}
*UPDATE*
The second issue about type cast separated into IGNITE-23183
was:
Update statements incorrectly use scalar subqueries in target columns, the
issues stems from the fact that scalar subquery in UPDATE are not wrapped in
`SINGLE_VAL` aggregate.
Examples:
{code:java}
@Test
public void ddml2() {
sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
INTEGER);");
sql("INSERT INTO vals VALUES (1, 0);");
sql("INSERT INTO vals VALUES (2, 0);");
sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
// works
sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
other_vals WHERE id = 1));");
// works
sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
WHERE id = 1");
// Should fail, because a subquery returns more than 1 result.
sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE id
>= 2");
}
UPDATEs in MERGE statement are also affect by this issue:
{code:java}
@Test
public void ddml2_1() {
sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
INTEGER);");
sql("INSERT INTO vals VALUES (1, 0);");
sql("INSERT INTO vals VALUES (2, 0);");
sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
// works
sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
other_vals WHERE id = 1));");
// Fails with PK unique constraint is violated
sql("MERGE INTO vals USING other_vals ON vals.id = other_vals.id "
+ "WHEN MATCHED THEN UPDATE SET val = (SELECT other_val FROM
other_vals WHERE id > 1) "
+ "WHEN NOT MATCHED THEN INSERT (id, val) VALUES (100, -1)");
}
{code}
{code}
If we change val type to BIGINT we get another error:
{code:java}
@Test
public void ddml3() {
sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
BIGINT);");
sql("INSERT INTO vals VALUES (1, 0);");
sql("INSERT INTO vals VALUES (2, 0);");
sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
// works
sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
other_vals WHERE id = 1));");
// works
sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
WHERE id = 1");
// Error
sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE id
>= 2");
}
{code}
Error:
{code:java}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:297)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.
[jira] [Assigned] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-23183:
-
Assignee: Pavel Pereslegin
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
> sql("UPDATE t0 set val = (select id::BIGINT from t0)");
> {code}
> fails with
> {noformat}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
> {noformat}
> Issue is caused by CALCITE-6570
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20835) Sql. Update statements incorrectly use scalar subqueries in target columns
[
https://issues.apache.org/jira/browse/IGNITE-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20835:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Update statements incorrectly use scalar subqueries in target columns
>
>
> Key: IGNITE-20835
> URL: https://issues.apache.org/jira/browse/IGNITE-20835
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update statements incorrectly use scalar subqueries in target columns, the
> issues stems from the fact that scalar subquery in UPDATE are not wrapped in
> `SINGLE_VAL` aggregate.
> Examples:
> {code:java}
> @Test
> public void ddml2() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> INTEGER);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // works
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
> WHERE id = 1");
> // Should fail, because a subquery returns more than 1 result.
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE
> id >= 2");
> }
> UPDATEs in MERGE statement are also affect by this issue:
> {code:java}
> @Test
> public void ddml2_1() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> INTEGER);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // Fails with PK unique constraint is violated
> sql("MERGE INTO vals USING other_vals ON vals.id = other_vals.id "
> + "WHEN MATCHED THEN UPDATE SET val = (SELECT other_val FROM
> other_vals WHERE id > 1) "
> + "WHEN NOT MATCHED THEN INSERT (id, val) VALUES (100, -1)");
> }
> {code}
> {code}
> If we change val type to BIGINT we get another error:
> {code:java}
> @Test
> public void ddml3() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> BIGINT);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // works
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
> WHERE id = 1");
> // Error
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE
> id >= 2");
> }
> {code}
> Error:
> {code:java}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:297)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:294)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:453)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:360)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:241)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5112)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5219)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:187)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSc
[jira] [Updated] (IGNITE-20835) Sql. Update statements incorrectly use scalar subqueries in target columns
[
https://issues.apache.org/jira/browse/IGNITE-20835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20835:
--
Priority: Major (was: Minor)
> Sql. Update statements incorrectly use scalar subqueries in target columns
>
>
> Key: IGNITE-20835
> URL: https://issues.apache.org/jira/browse/IGNITE-20835
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update statements incorrectly use scalar subqueries in target columns, the
> issues stems from the fact that scalar subquery in UPDATE are not wrapped in
> `SINGLE_VAL` aggregate.
> Examples:
> {code:java}
> @Test
> public void ddml2() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> INTEGER);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // works
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
> WHERE id = 1");
> // Should fail, because a subquery returns more than 1 result.
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE
> id >= 2");
> }
> UPDATEs in MERGE statement are also affect by this issue:
> {code:java}
> @Test
> public void ddml2_1() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> INTEGER);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // Fails with PK unique constraint is violated
> sql("MERGE INTO vals USING other_vals ON vals.id = other_vals.id "
> + "WHEN MATCHED THEN UPDATE SET val = (SELECT other_val FROM
> other_vals WHERE id > 1) "
> + "WHEN NOT MATCHED THEN INSERT (id, val) VALUES (100, -1)");
> }
> {code}
> {code}
> If we change val type to BIGINT we get another error:
> {code:java}
> @Test
> public void ddml3() {
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val INTEGER);");
> sql("CREATE TABLE other_vals (id INTEGER PRIMARY KEY, other_val
> BIGINT);");
> sql("INSERT INTO vals VALUES (1, 0);");
> sql("INSERT INTO vals VALUES (2, 0);");
> sql("INSERT INTO other_vals VALUES (1, 1), (2, 2);");
> // works
> sql("INSERT INTO other_vals VALUES (3, (SELECT other_val FROM
> other_vals WHERE id = 1));");
> // works
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals LIMIT 1)
> WHERE id = 1");
> // Error
> sql("UPDATE vals SET val = (SELECT other_val FROM other_vals) WHERE
> id >= 2");
> }
> {code}
> Error:
> {code:java}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:297)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:294)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:453)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:360)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:241)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5112)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5219)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:187)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImp
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fail with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
was:
Reproducer:
{code:java}
@Test
public void testUpdateDiffTypes() {
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
}
{code}
fail with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
> Issue Type: Bug
> Compone
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Description:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fails with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
was:
Reproducer:
{code:java}
sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
sql("UPDATE t0 set val = (select id::BIGINT from t0)");
{code}
fail with
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
at
org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
at
org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
{noformat}
Issue is caused by CALCITE-6570
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>P
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Component/s: sql
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Reproducer:
> {code:java}
> @Test
> public void testUpdateDiffTypes() {
> sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
> sql("UPDATE t0 set val = (select id::BIGINT from t0)");
> }
> {code}
> fail with
> {noformat}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
> {noformat}
> Issue is caused by CALCITE-6570
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23183) Sql. Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/IGNITE-23183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23183:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Assertion error when validating an UPDATE query with a subquery
> expression
> ---
>
> Key: IGNITE-23183
> URL: https://issues.apache.org/jira/browse/IGNITE-23183
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Reproducer:
> {code:java}
> @Test
> public void testUpdateDiffTypes() {
> sql("CREATE TABLE t0(ID INT PRIMARY KEY, VAL INT)");
> sql("UPDATE t0 set val = (select id::BIGINT from t0)");
> }
> {code}
> fail with
> {noformat}
> Caused by: java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.needToCast(IgniteTypeCoercion.java:321)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.doCoerceColumnType(IgniteTypeCoercion.java:499)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.coerceColumnType(IgniteTypeCoercion.java:406)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteTypeCoercion.querySourceCoercion(IgniteTypeCoercion.java:278)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5272)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5379)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateUpdate(IgniteSqlValidator.java:229)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1101)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:807)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validate(IgniteSqlValidator.java:176)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validate(IgnitePlanner.java:200)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareDml$8(PrepareServiceImpl.java:515)
> {noformat}
> Issue is caused by CALCITE-6570
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23164) ClientKeyValueBinaryView.get() operation returns tuple with key column
[
https://issues.apache.org/jira/browse/IGNITE-23164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23164:
--
Description:
The tuple returned by {{ClientKeyValueBinaryView.get()}} method must have only
value fields.
But we still can access the key column using the column name.
Reproducer (for ClientKeyValueBinaryViewTest):
{code:java}
@Test
public void testGet() {
KeyValueView kvView = defaultTable().keyValueView();
Tuple key = tupleKey(1);
// insert tuple (id=1, name="test)
kvView.put(null, key, tupleVal("test"));
// get value by key
Tuple val = kvView.get(null, key);
// correct
assertEquals(1, val.columnCount());
assertEquals("test", val.value(0));
assertEquals("test", val.value("name"));
// incorrect
assertEquals(1L, val.longValue("id"));
}
{code}
was:
The tuple returned by {{ClientKeyValueBinaryView.get()}} method must have only
value fields.
But we can access the key column using the column name.
Reproducer (for ClientKeyValueBinaryViewTest):
{code:java}
@Test
public void testGet() {
KeyValueView kvView = defaultTable().keyValueView();
Tuple key = tupleKey(1);
// insert tuple (id=1, name="test)
kvView.put(null, key, tupleVal("test"));
// get value by key
Tuple val = kvView.get(null, key);
// correct
assertEquals(1, val.columnCount());
assertEquals("test", val.value(0));
assertEquals("test", val.value("name"));
// incorrect
assertEquals(1L, val.longValue("id"));
}
{code}
> ClientKeyValueBinaryView.get() operation returns tuple with key column
> --
>
> Key: IGNITE-23164
> URL: https://issues.apache.org/jira/browse/IGNITE-23164
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The tuple returned by {{ClientKeyValueBinaryView.get()}} method must have
> only value fields.
> But we still can access the key column using the column name.
> Reproducer (for ClientKeyValueBinaryViewTest):
> {code:java}
> @Test
> public void testGet() {
> KeyValueView kvView = defaultTable().keyValueView();
> Tuple key = tupleKey(1);
> // insert tuple (id=1, name="test)
> kvView.put(null, key, tupleVal("test"));
> // get value by key
> Tuple val = kvView.get(null, key);
> // correct
> assertEquals(1, val.columnCount());
> assertEquals("test", val.value(0));
> assertEquals("test", val.value("name"));
> // incorrect
> assertEquals(1L, val.longValue("id"));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23164) Incorrect behaviour of ClientKeyValueBinaryView.get() operation
[
https://issues.apache.org/jira/browse/IGNITE-23164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23164:
--
Description:
The tuple returned by "get()" method must have only value fields.
But we can access to key column using column name.
Reproducer (ClientKeyValueBinaryViewTest):
{code:java}
@Test
public void testGet() {
KeyValueView kvView = defaultTable().keyValueView();
Tuple key = tupleKey(1);
// insert tuple (id=1, name="test)
kvView.put(null, key, tupleVal("test"));
// get value by key
Tuple val = kvView.get(null, key);
// correct
assertEquals(1, val.columnCount());
assertEquals("test", val.value(0));
assertEquals("test", val.value("name"));
// incorrect
assertEquals(1L, val.longValue("id"));
}
{code}
was:
Tuple that returns from "get()" method must have only value-fields.
But we can access to key column using column name.
Reproducer (ClientKeyValueBinaryViewTest):
{code:java}
@Test
public void testGet() {
KeyValueView kvView = defaultTable().keyValueView();
Tuple key = tupleKey(1);
// insert tuple (id=1, name="test)
kvView.put(null, key, tupleVal("test"));
// get value by key
Tuple val = kvView.get(null, key);
// correct
assertEquals(1, val.columnCount());
assertEquals("test", val.value(0));
assertEquals("test", val.value("name"));
// incorrect
assertEquals(1L, val.longValue("id"));
}
{code}
> Incorrect behaviour of ClientKeyValueBinaryView.get() operation
> ---
>
> Key: IGNITE-23164
> URL: https://issues.apache.org/jira/browse/IGNITE-23164
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The tuple returned by "get()" method must have only value fields.
> But we can access to key column using column name.
> Reproducer (ClientKeyValueBinaryViewTest):
> {code:java}
> @Test
> public void testGet() {
> KeyValueView kvView = defaultTable().keyValueView();
> Tuple key = tupleKey(1);
> // insert tuple (id=1, name="test)
> kvView.put(null, key, tupleVal("test"));
> // get value by key
> Tuple val = kvView.get(null, key);
> // correct
> assertEquals(1, val.columnCount());
> assertEquals("test", val.value(0));
> assertEquals("test", val.value("name"));
> // incorrect
> assertEquals(1L, val.longValue("id"));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23164) Incorrect behaviour of ClientKeyValueBinaryView.get() operation
Pavel Pereslegin created IGNITE-23164:
-
Summary: Incorrect behaviour of ClientKeyValueBinaryView.get()
operation
Key: IGNITE-23164
URL: https://issues.apache.org/jira/browse/IGNITE-23164
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Pavel Pereslegin
Tuple that returns from "get()" method must have only value-fields.
But we can access to key column using column name.
Reproducer (ClientKeyValueBinaryViewTest):
{code:java}
@Test
public void testGet() {
KeyValueView kvView = defaultTable().keyValueView();
Tuple key = tupleKey(1);
// insert tuple (id=1, name="test)
kvView.put(null, key, tupleVal("test"));
// get value by key
Tuple val = kvView.get(null, key);
// correct
assertEquals(1, val.columnCount());
assertEquals("test", val.value(0));
assertEquals("test", val.value("name"));
// incorrect
assertEquals(1L, val.longValue("id"));
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22712) Catalog compaction. Describe catalog compaction in README.md
[ https://issues.apache.org/jira/browse/IGNITE-22712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879427#comment-17879427 ] Pavel Pereslegin edited comment on IGNITE-22712 at 9/6/24 7:54 AM: --- [~zstan], review proposed changes, please. Use this link to see the rendered document: https://github.com/apache/ignite-3/blob/5ad941f73a826626203e9df72ef0eff4f0a4217f/modules/catalog-compaction/README.md was (Author: xtern): [~zstan], review proposed changes, please. Use this link to see the rendered document: https://github.com/apache/ignite-3/blob/b4c45ac3e50ed4c1bc08d8e2894a86aaf91cb77b/modules/catalog-compaction/README.md > Catalog compaction. Describe catalog compaction in README.md > > > Key: IGNITE-22712 > URL: https://issues.apache.org/jira/browse/IGNITE-22712 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Describe catalog compaction in README.md in catalog compaction module > directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22712) Catalog compaction. Describe catalog compaction in README.md
[ https://issues.apache.org/jira/browse/IGNITE-22712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879427#comment-17879427 ] Pavel Pereslegin edited comment on IGNITE-22712 at 9/5/24 12:39 PM: [~zstan], review proposed changes, please. Use this link to see the rendered document: https://github.com/apache/ignite-3/blob/b4c45ac3e50ed4c1bc08d8e2894a86aaf91cb77b/modules/catalog-compaction/README.md was (Author: xtern): [~zstan], review proposed changes, please. Use this link to see the rendered document: https://github.com/apache/ignite-3/blob/f5ed2910a1a3e2a9662626bd73c022ad78785619/modules/catalog-compaction/README.md > Catalog compaction. Describe catalog compaction in README.md > > > Key: IGNITE-22712 > URL: https://issues.apache.org/jira/browse/IGNITE-22712 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Describe catalog compaction in README.md in catalog compaction module > directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22712) Catalog compaction. Describe catalog compaction in README.md
[ https://issues.apache.org/jira/browse/IGNITE-22712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879544#comment-17879544 ] Pavel Pereslegin commented on IGNITE-22712: --- [~korlov] review catalog compaction module description, please. Use this link to see rendered document: https://github.com/apache/ignite-3/blob/b4c45ac3e50ed4c1bc08d8e2894a86aaf91cb77b/modules/catalog-compaction/README.md > Catalog compaction. Describe catalog compaction in README.md > > > Key: IGNITE-22712 > URL: https://issues.apache.org/jira/browse/IGNITE-22712 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Describe catalog compaction in README.md in catalog compaction module > directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23003) KeyValueBinaryView::getNullable should not throw UnsupportedOperation exception
[ https://issues.apache.org/jira/browse/IGNITE-23003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-23003: - Assignee: Pavel Pereslegin > KeyValueBinaryView::getNullable should not throw UnsupportedOperation > exception > --- > > Key: IGNITE-23003 > URL: https://issues.apache.org/jira/browse/IGNITE-23003 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Zhuravkov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > KeyValueBinaryView::getNullable should return behave as the same way as > KeyValueBinaryView::getAsync but return Nullable when if a value exists. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22712) Catalog compaction. Describe catalog compaction in README.md
[ https://issues.apache.org/jira/browse/IGNITE-22712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879427#comment-17879427 ] Pavel Pereslegin edited comment on IGNITE-22712 at 9/5/24 5:22 AM: --- [~zstan], review proposed changes, please. Use this link to see the rendered document: https://github.com/apache/ignite-3/blob/f5ed2910a1a3e2a9662626bd73c022ad78785619/modules/catalog-compaction/README.md was (Author: xtern): [~zstan], review proposed changes, please. Use this link to view rendered document: https://github.com/apache/ignite-3/blob/f5ed2910a1a3e2a9662626bd73c022ad78785619/modules/catalog-compaction/README.md > Catalog compaction. Describe catalog compaction in README.md > > > Key: IGNITE-22712 > URL: https://issues.apache.org/jira/browse/IGNITE-22712 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Describe catalog compaction in README.md in catalog compaction module > directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22712) Catalog compaction. Describe catalog compaction in README.md
[ https://issues.apache.org/jira/browse/IGNITE-22712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-22712: -- Fix Version/s: 3.0 > Catalog compaction. Describe catalog compaction in README.md > > > Key: IGNITE-22712 > URL: https://issues.apache.org/jira/browse/IGNITE-22712 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Describe catalog compaction in README.md in catalog compaction module > directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23078) Fix flaky test CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
[
https://issues.apache.org/jira/browse/IGNITE-23078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878551#comment-17878551
]
Pavel Pereslegin commented on IGNITE-23078:
---
[~korlov], take a look at this small fix, please.
> Fix flaky test
> CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
>
>
> Key: IGNITE-23078
> URL: https://issues.apache.org/jira/browse/IGNITE-23078
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test fails with the following (reproduces locally):
> {code:java}
> java.lang.AssertionError:
> Expected: is <5>
> but: was <1>
> Expected :is <5>
> Actual :<1>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> {code}
> See
> https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
> *Update*
> Must be fixed in IGNITE-22637
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23042) Sql. Forbid implicit casts between different type families
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878549#comment-17878549 ] Pavel Pereslegin commented on IGNITE-23042: --- Looks like issue IGNITE-23060 should be resolved when this IGNITE-23042 will be resolved (check TODO related to IGNITE-23060). > Sql. Forbid implicit casts between different type families > -- > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type casts (of which types) during DML from one > table to another. > * Whether to allow implicit casts in operations. > * Whether to allow implicit casts for function operands. > * ... > *Update* > During the discussion it was decided to forbid any implicit casts between > different type families. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23078) Fix flaky test CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
[
https://issues.apache.org/jira/browse/IGNITE-23078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-23078:
-
Assignee: Pavel Pereslegin
> Fix flaky test
> CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
>
>
> Key: IGNITE-23078
> URL: https://issues.apache.org/jira/browse/IGNITE-23078
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test fails with the following (reproduces locally):
> {code:java}
> java.lang.AssertionError:
> Expected: is <5>
> but: was <1>
> Expected :is <5>
> Actual :<1>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> {code}
> See
> https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
> *Update*
> Must be fixed in IGNITE-22637
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23078) Fix flaky test CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
[
https://issues.apache.org/jira/browse/IGNITE-23078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23078:
--
Fix Version/s: 3.0.0-beta2
> Fix flaky test
> CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
>
>
> Key: IGNITE-23078
> URL: https://issues.apache.org/jira/browse/IGNITE-23078
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test fails with the following (reproduces locally):
> {code:java}
> java.lang.AssertionError:
> Expected: is <5>
> but: was <1>
> Expected :is <5>
> Actual :<1>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> {code}
> See
> https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
> *Update*
> Must be fixed in IGNITE-22637
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22712) Catalog compaction. Describe catalog compaction in README.md
[ https://issues.apache.org/jira/browse/IGNITE-22712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-22712: - Assignee: Pavel Pereslegin > Catalog compaction. Describe catalog compaction in README.md > > > Key: IGNITE-22712 > URL: https://issues.apache.org/jira/browse/IGNITE-22712 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Describe catalog compaction in README.md in catalog compaction module > directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23078) Fix flaky test CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
[
https://issues.apache.org/jira/browse/IGNITE-23078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23078:
--
Description:
Test fails with the following (reproduces locally):
{code:java}
java.lang.AssertionError:
Expected: is <5>
but: was <1>
Expected :is <5>
Actual :<1>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
{code}
See
https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
*Update*
Must be fixed in IGNITE-22637
was:
Test fails with the following (reproduces locally):
{code:java}
java.lang.AssertionError:
Expected: is <5>
but: was <1>
Expected :is <5>
Actual :<1>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
{code}
See
https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
Update: test must be fixed in IGNITE-22637
> Fix flaky test
> CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
>
>
> Key: IGNITE-23078
> URL: https://issues.apache.org/jira/browse/IGNITE-23078
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Test fails with the following (reproduces locally):
> {code:java}
> java.lang.AssertionError:
> Expected: is <5>
> but: was <1>
> Expected :is <5>
> Actual :<1>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> {code}
> See
> https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
> *Update*
> Must be fixed in IGNITE-22637
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23078) Fix flaky test CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
[
https://issues.apache.org/jira/browse/IGNITE-23078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23078:
--
Description:
Test fails with the following (reproduces locally):
{code:java}
java.lang.AssertionError:
Expected: is <5>
but: was <1>
Expected :is <5>
Actual :<1>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
{code}
See
https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
Update: test must be fixed in IGNITE-22637
was:
Test fails with the following (reproduces locally):
{code:java}
java.lang.AssertionError:
Expected: is <5>
but: was <1>
Expected :is <5>
Actual :<1>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
{code}
See
https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
> Fix flaky test
> CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
>
>
> Key: IGNITE-23078
> URL: https://issues.apache.org/jira/browse/IGNITE-23078
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Test fails with the following (reproduces locally):
> {code:java}
> java.lang.AssertionError:
> Expected: is <5>
> but: was <1>
> Expected :is <5>
> Actual :<1>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> {code}
> See
> https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
> Update: test must be fixed in IGNITE-22637
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23078) Fix flaky test CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
Pavel Pereslegin created IGNITE-23078:
-
Summary: Fix flaky test
CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing
Key: IGNITE-23078
URL: https://issues.apache.org/jira/browse/IGNITE-23078
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Pereslegin
Test fails with the following (reproduces locally):
{code:java}
java.lang.AssertionError:
Expected: is <5>
but: was <1>
Expected :is <5>
Actual :<1>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.catalog.compaction.CatalogCompactionRunnerSelfTest.mustNotPerformWhenAssignmentNodeIsMissing(CatalogCompactionRunnerSelfTest.java:447)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
{code}
See
https://ci.ignite.apache.org/viewLog.html?buildId=8428446&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunUnitTests_virtual_Batch_3_1#testNameId-2776474029566024508
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23042) Sql. Forbid implicit casts between different type families
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23042: -- Summary: Sql. Forbid implicit casts between different type families (was: Sql. Revise the rules for implicit type casts) > Sql. Forbid implicit casts between different type families > -- > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type casts (of which types) during DML from one > table to another. > * Whether to allow implicit casts in operations. > * Whether to allow implicit casts for function operands. > * ... > *Update* > During the discussion it was decided to forbid any implicit casts between > different type families. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23042) Sql. Revise the rules for implicit type casts
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23042: -- Description: At the moment, the rules for implicit type conversion are not formalized. As a result, we allow implicit casting of types from different families everywhere (including for function operands, which can be confusing). We need to formalize the rules for safe implicit conversion and follow them. * Whether to allow implicit type casts (of which types) during DML from one table to another. * Whether to allow implicit casts in operations. * Whether to allow implicit casts for function operands. * ... *Update* During the discussion it was decided to forbid any implicit casts between different type families. was: At the moment, the rules for implicit type conversion are not formalized. As a result, we allow implicit casting of types from different families everywhere (including for function operands, which can be confusing). We need to formalize the rules for safe implicit conversion and follow them. * Whether to allow implicit type casts (of which types) during DML from one table to another. * Whether to allow implicit casts in operations. * Whether to allow implicit casts for function operands. * ... > Sql. Revise the rules for implicit type casts > - > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type casts (of which types) during DML from one > table to another. > * Whether to allow implicit casts in operations. > * Whether to allow implicit casts for function operands. > * ... > *Update* > During the discussion it was decided to forbid any implicit casts between > different type families. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22951) Catalog compaction. Improve minimum tx begin time propagation to replicas
[
https://issues.apache.org/jira/browse/IGNITE-22951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22951:
--
Fix Version/s: 3.0.0-beta2
> Catalog compaction. Improve minimum tx begin time propagation to replicas
> -
>
> Key: IGNITE-22951
> URL: https://issues.apache.org/jira/browse/IGNITE-22951
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> After IGNITE-22641, for each catalog compaction run we have a {{N x M}}
> replica requests, where N - count of tables, M - count of partitions.
> This looks extremely inefficient and we should consider using:
> * Message coalescing.
> * Depending on whether you actually need compaction coordinator or it's
> possible to trigger minBeginTxTime on all nodes consider sending requests to
> self only.
> * Adding some randomization on sending requests between replication groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23060) Sql. Move rules from typeFamiliesAreCompatible into IgniteCustomAssignmentsRules
[
https://issues.apache.org/jira/browse/IGNITE-23060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23060:
--
Description:
{{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible type
families taking into account custom data types (types have compatible type
families if type can be assigned to another type and vice-versa)
{{IgniteCustomAssignmentsRules}} is more relaxed and determines whether a type
is assignable from another type , but doesn't take into account custom types
(currently it operates with {{SqlTypeName}}, not {{RelDataType}}).
Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
{{IgniteCustomAssignmentsRules}} if possible.
was:
{{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible type
families taking into account custom data types (types have compatible type
families if type can be assigned to another type and vice-versa)
{{IgniteCustomAssignmentsRules}} is more relaxed and determines whether a type
is assignable from another type , but doesn't take into account custom types
(currently operates with SqlTypeName not RelDataType).
Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
{{IgniteCustomAssignmentsRules}} if possible.
> Sql. Move rules from typeFamiliesAreCompatible into
> IgniteCustomAssignmentsRules
>
>
> Key: IGNITE-23060
> URL: https://issues.apache.org/jira/browse/IGNITE-23060
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible
> type families taking into account custom data types (types have compatible
> type families if type can be assigned to another type and vice-versa)
> {{IgniteCustomAssignmentsRules}} is more relaxed and determines whether a
> type is assignable from another type , but doesn't take into account custom
> types (currently it operates with {{SqlTypeName}}, not {{RelDataType}}).
> Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
> {{IgniteCustomAssignmentsRules}} if possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23060) Sql. Move rules from typeFamiliesAreCompatible into IgniteCustomAssignmentsRules
[
https://issues.apache.org/jira/browse/IGNITE-23060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23060:
--
Description:
{{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible type
families taking into account custom data types (types have compatible type
families if type can be assigned to another type and vice-versa)
{{IgniteCustomAssignmentsRules}} is more relaxed and determines whether a type
is assignable from another type , but doesn't take into account custom types
(currently operates with SqlTypeName not RelDataType).
Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
{{IgniteCustomAssignmentsRules}} if possible.
was:
{{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible type
families taking into account custom data types (types have compatible type
families if type can be assigned to another type and vice-versa)
{{IgniteCustomAssignmentsRules}} is more relaxed and determine whether a type
is assignable from another type , but doesn't take into account custom types
(currently operates with SqlTypeName not RelDataType).
Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
{{IgniteCustomAssignmentsRules}} if possible.
> Sql. Move rules from typeFamiliesAreCompatible into
> IgniteCustomAssignmentsRules
>
>
> Key: IGNITE-23060
> URL: https://issues.apache.org/jira/browse/IGNITE-23060
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible
> type families taking into account custom data types (types have compatible
> type families if type can be assigned to another type and vice-versa)
> {{IgniteCustomAssignmentsRules}} is more relaxed and determines whether a
> type is assignable from another type , but doesn't take into account custom
> types (currently operates with SqlTypeName not RelDataType).
> Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
> {{IgniteCustomAssignmentsRules}} if possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23060) Sql. Move rules from typeFamiliesAreCompatible into IgniteCustomAssignmentsRules
[
https://issues.apache.org/jira/browse/IGNITE-23060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23060:
--
Description:
{{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible type
families taking into account custom data types (types have compatible type
families if type can be assigned to another type and vice-versa)
{{IgniteCustomAssignmentsRules}} is more relaxed and determine whether a type
is assignable from another type , but doesn't take into account custom types
(currently operates with SqlTypeName not RelDataType).
Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
{{IgniteCustomAssignmentsRules}} if possible.
was:
{{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible type
families taking into account custom data types (types have compatible type
families if type can be assigned to another type and and vice-versa)
{{IgniteCustomAssignmentsRules}} is more relaxed and determine whether a type
is assignable from another type , but doesn't take into account custom types
(currently operates with SqlTypeName not RelDataType).
Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
{{IgniteCustomAssignmentsRules}} if possible.
> Sql. Move rules from typeFamiliesAreCompatible into
> IgniteCustomAssignmentsRules
>
>
> Key: IGNITE-23060
> URL: https://issues.apache.org/jira/browse/IGNITE-23060
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> {{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible
> type families taking into account custom data types (types have compatible
> type families if type can be assigned to another type and vice-versa)
> {{IgniteCustomAssignmentsRules}} is more relaxed and determine whether a type
> is assignable from another type , but doesn't take into account custom types
> (currently operates with SqlTypeName not RelDataType).
> Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
> {{IgniteCustomAssignmentsRules}} if possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23060) Sql. Move rules from typeFamiliesAreCompatible into IgniteCustomAssignmentsRules
Pavel Pereslegin created IGNITE-23060:
-
Summary: Sql. Move rules from typeFamiliesAreCompatible into
IgniteCustomAssignmentsRules
Key: IGNITE-23060
URL: https://issues.apache.org/jira/browse/IGNITE-23060
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Pavel Pereslegin
{{TypeUtils.typeFamiliesAreCompatible}} checks that types have compatible type
families taking into account custom data types (types have compatible type
families if type can be assigned to another type and and vice-versa)
{{IgniteCustomAssignmentsRules}} is more relaxed and determine whether a type
is assignable from another type , but doesn't take into account custom types
(currently operates with SqlTypeName not RelDataType).
Looks like we need to move checks from {{typeFamiliesAreCompatible}} into
{{IgniteCustomAssignmentsRules}} if possible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23042) Sql. Revise the rules for implicit type casts
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23042: -- Description: At the moment, the rules for implicit type conversion are not formalized. As a result, we allow implicit casting of types from different families everywhere (including for function operands, which can be confusing). We need to formalize the rules for safe implicit conversion and follow them. * Whether to allow implicit type casts (of which types) during DML from one table to another. * Whether to allow implicit casts in operations. * Whether to allow implicit casts for function operands. * ... was: At the moment, the rules for implicit type conversion are not formalized. As a result, we allow implicit casting of types from different families everywhere (including for function operands, which can be confusing). We need to formalize the rules for safe implicit conversion and follow them. * Whether to allow implicit type conversions (of which types) during DML from one table to another. * Whether to allow implicit conversions in operations. * Whether to allow implicit conversions for function operands. * ... > Sql. Revise the rules for implicit type casts > - > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type casts (of which types) during DML from one > table to another. > * Whether to allow implicit casts in operations. > * Whether to allow implicit casts for function operands. > * ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23042) Sql. Revise the rules for implicit type casts
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23042: -- Summary: Sql. Revise the rules for implicit type casts (was: Sql. Revise the rules for implicit type conversions) > Sql. Revise the rules for implicit type casts > - > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type conversions (of which types) during DML from > one table to another. > * Whether to allow implicit conversions in operations. > * Whether to allow implicit conversions for function operands. > * ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23042) Sql. Revise the rules for implicit type conversions
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23042: -- Component/s: sql > Sql. Revise the rules for implicit type conversions > --- > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type conversions (of which types) during DML from > one table to another. > * Whether to allow implicit conversions in operations. > * Whether to allow implicit conversions for function operands. > * ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23042) Sql. Revise the rules for implicit type conversions
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23042: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Revise the rules for implicit type conversions > --- > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type conversions (of which types) during DML from > one table to another. > * Whether to allow implicit conversions in operations. > * Whether to allow implicit conversions for function operands. > * ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23042) Sql. Revise the rules for implicit type conversions
Pavel Pereslegin created IGNITE-23042: - Summary: Sql. Revise the rules for implicit type conversions Key: IGNITE-23042 URL: https://issues.apache.org/jira/browse/IGNITE-23042 Project: Ignite Issue Type: Improvement Reporter: Pavel Pereslegin At the moment, the rules for implicit type conversion are not formalized. As a result, we allow implicit casting of types from different families everywhere (including for function operands, which can be confusing). We need to formalize the rules for safe implicit conversion and follow them. * Whether to allow implicit type conversions (of which types) during DML from one table to another. * Whether to allow implicit conversions in operations. * Whether to allow implicit conversions for function operands. * ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23042) Sql. Revise the rules for implicit type conversions
[ https://issues.apache.org/jira/browse/IGNITE-23042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23042: -- Labels: ignite-3 (was: ) > Sql. Revise the rules for implicit type conversions > --- > > Key: IGNITE-23042 > URL: https://issues.apache.org/jira/browse/IGNITE-23042 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > At the moment, the rules for implicit type conversion are not formalized. As > a result, we allow implicit casting of types from different families > everywhere (including for function operands, which can be confusing). > We need to formalize the rules for safe implicit conversion and follow them. > * Whether to allow implicit type conversions (of which types) during DML from > one table to another. > * Whether to allow implicit conversions in operations. > * Whether to allow implicit conversions for function operands. > * ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23039) Sql. Add support for Sarg serialization/deserialization
[
https://issues.apache.org/jira/browse/IGNITE-23039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23039:
--
Description:
Currently when serializing {{Sarg}} ({{SEARCH}} operator) we converting it to
OR (using {{Rextil.exapndSearch()}}) .
But since 1.35 calcite supports serialization of {{Sarg}} (see CALCITE-5614).
Need to port this code to AI.
p.s. check TODOs
was:
Currently when serializing {{Sarg}} ({{SEARCH}} operator) we converting it to
OR (using {{Rextil.exapndSearch()}}) .
But since 1.35 calcite supports serialization of {{Sarg}} (see CALCITE-5614).
Need to port this code to AI.
> Sql. Add support for Sarg serialization/deserialization
> ---
>
> Key: IGNITE-23039
> URL: https://issues.apache.org/jira/browse/IGNITE-23039
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently when serializing {{Sarg}} ({{SEARCH}} operator) we converting it to
> OR (using {{Rextil.exapndSearch()}}) .
> But since 1.35 calcite supports serialization of {{Sarg}} (see CALCITE-5614).
> Need to port this code to AI.
> p.s. check TODOs
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23039) Sql. Add support for Sarg serialization/deserialization
[
https://issues.apache.org/jira/browse/IGNITE-23039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-23039:
--
Description:
Currently when serializing {{Sarg}} ({{SEARCH}} operator) we converting it to
OR (using {{Rextil.exapndSearch()}}) .
But since 1.35 calcite supports serialization of {{Sarg}} (see CALCITE-5614).
Need to port this code to AI.
was:
Currently when serializing Sarg (SEARCH operator) we converting it to OR (using
Rextil.exapndSearch()) .
But since 1.35 calcite supports serialization of Sarg (see CALCITE-5614).
Need to port this code to AI.
> Sql. Add support for Sarg serialization/deserialization
> ---
>
> Key: IGNITE-23039
> URL: https://issues.apache.org/jira/browse/IGNITE-23039
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently when serializing {{Sarg}} ({{SEARCH}} operator) we converting it to
> OR (using {{Rextil.exapndSearch()}}) .
> But since 1.35 calcite supports serialization of {{Sarg}} (see CALCITE-5614).
> Need to port this code to AI.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23039) Sql. Add support for Sarg serialization/deserialization
[ https://issues.apache.org/jira/browse/IGNITE-23039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23039: -- Description: Currently when serializing Sarg (SEARCH operator) we converting it to OR (using Rextil.exapndSearch()) . But since 1.35 calcite supports serialization of Sarg (see CALCITE-5614). Need to port this code to AI. was: Currently when serializing Sarg (SEARCH operator) we converting it to OR (using Rextil.exapndSearch . But since 1.35 calcite supports serialization of Sarg (see CALCITE-5614). Need to port this code to AI. > Sql. Add support for Sarg serialization/deserialization > --- > > Key: IGNITE-23039 > URL: https://issues.apache.org/jira/browse/IGNITE-23039 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Currently when serializing Sarg (SEARCH operator) we converting it to OR > (using Rextil.exapndSearch()) . > But since 1.35 calcite supports serialization of Sarg (see CALCITE-5614). > Need to port this code to AI. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23039) Sql. Add support for Sarg serialization/deserialization
[ https://issues.apache.org/jira/browse/IGNITE-23039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-23039: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Add support for Sarg serialization/deserialization > --- > > Key: IGNITE-23039 > URL: https://issues.apache.org/jira/browse/IGNITE-23039 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Currently when serializing Sarg (SEARCH operator) we converting it to OR > (using Rextil.exapndSearch . > But since 1.35 calcite supports serialization of Sarg (see CALCITE-5614). > Need to port this code to AI. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23039) Sql. Add support for Sarg serialization/deserialization
Pavel Pereslegin created IGNITE-23039: - Summary: Sql. Add support for Sarg serialization/deserialization Key: IGNITE-23039 URL: https://issues.apache.org/jira/browse/IGNITE-23039 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Pereslegin Currently when serializing Sarg (SEARCH operator) we converting it to OR (using Rextil.exapndSearch . But since 1.35 calcite supports serialization of Sarg (see CALCITE-5614). Need to port this code to AI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19469) Sql. Functions. Type coercion of function arguments (SUBSTR function).
[
https://issues.apache.org/jira/browse/IGNITE-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875218#comment-17875218
]
Pavel Pereslegin edited comment on IGNITE-19469 at 8/20/24 4:00 PM:
I think the same applies to {{LENGTH()}}.
Currently, the following query
{code:sql}
SELECT LENGTH(1234)
{code}
generates the following projection
{code}
Project(EXPR$0=[LENGTH(_UTF-8'1234':VARCHAR CHARACTER SET "UTF-8")])
{code}
and works fine, but should fail during validation
was (Author: xtern):
I think the same applies to {{LENGTH()}}.
Currently, the following query works fine
{code:sql}
SELECT LENGTH(1234)
{code}
But should produce a validation error
> Sql. Functions. Type coercion of function arguments (SUBSTR function).
> --
>
> Key: IGNITE-19469
> URL: https://issues.apache.org/jira/browse/IGNITE-19469
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Calls to SUBSTR function with arguments of not compatible types does not
> cause validation errors in some cases:
> {code:java}
> # 1
> SELECT SUBSTR(100, 1)}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'100':VARCHAR CHARACTER SET "UTF-8", 1)]),
> id = 20
> IgniteValues(tuples=[[{ 0 }]]), id = 18
> # 2
> SELECT SUBSTR('123456789', '1')}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', 1:BIGINT)]), id = 41
> IgniteValues(tuples=[[{ 0 }]]), id = 39
> {code}
> # 3
> SELECT SUBSTR(''::UUID, 1)}
> IgniteProject(EXPR$0=[SUBSTR(CAST(_UTF-8''):UUID NOT NULL, 1)]), id = 83
> IgniteValues(tuples=[[{ 0 }]]), id = 81
> # 4
> SELECT SUBSTR('123456789', ?, 1)
> Dynamic parameters: [---- ]
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', ?0, 1)]), id = 104
> IgniteValues(tuples=[[{ 0 }]]), id = 102
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19469) Sql. Functions. Type coercion of function arguments (SUBSTR function).
[
https://issues.apache.org/jira/browse/IGNITE-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875218#comment-17875218
]
Pavel Pereslegin edited comment on IGNITE-19469 at 8/20/24 3:14 PM:
I think the same applies to {{LENGTH()}}.
Currently, the following query works fine
{code:sql}
SELECT LENGTH(1234)
{code}
But should produce a validation error
was (Author: xtern):
I think the same applies to {{LENGTH()}}.
In the AI3 the following query works fine
{code:sql}
SELECT LENGTH(1234)
{code}
But should produce a validation error
> Sql. Functions. Type coercion of function arguments (SUBSTR function).
> --
>
> Key: IGNITE-19469
> URL: https://issues.apache.org/jira/browse/IGNITE-19469
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Calls to SUBSTR function with arguments of not compatible types does not
> cause validation errors in some cases:
> {code:java}
> # 1
> SELECT SUBSTR(100, 1)}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'100':VARCHAR CHARACTER SET "UTF-8", 1)]),
> id = 20
> IgniteValues(tuples=[[{ 0 }]]), id = 18
> # 2
> SELECT SUBSTR('123456789', '1')}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', 1:BIGINT)]), id = 41
> IgniteValues(tuples=[[{ 0 }]]), id = 39
> {code}
> # 3
> SELECT SUBSTR(''::UUID, 1)}
> IgniteProject(EXPR$0=[SUBSTR(CAST(_UTF-8''):UUID NOT NULL, 1)]), id = 83
> IgniteValues(tuples=[[{ 0 }]]), id = 81
> # 4
> SELECT SUBSTR('123456789', ?, 1)
> Dynamic parameters: [---- ]
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', ?0, 1)]), id = 104
> IgniteValues(tuples=[[{ 0 }]]), id = 102
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19469) Sql. Functions. Type coercion of function arguments (SUBSTR function).
[
https://issues.apache.org/jira/browse/IGNITE-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875218#comment-17875218
]
Pavel Pereslegin edited comment on IGNITE-19469 at 8/20/24 3:14 PM:
I think the same applies to {{LENGTH()}}.
In the AI3 the following query works fine
{code:sql}
SELECT LENGTH(1234)
{code}
But should produce a validation error
was (Author: xtern):
I think the same applies to {{LENGTH()}}.
In the AI3 the following query works fine
{code:java}
SELECT LENGTH(1234)
{code}
But should produce a validation error
> Sql. Functions. Type coercion of function arguments (SUBSTR function).
> --
>
> Key: IGNITE-19469
> URL: https://issues.apache.org/jira/browse/IGNITE-19469
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Calls to SUBSTR function with arguments of not compatible types does not
> cause validation errors in some cases:
> {code:java}
> # 1
> SELECT SUBSTR(100, 1)}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'100':VARCHAR CHARACTER SET "UTF-8", 1)]),
> id = 20
> IgniteValues(tuples=[[{ 0 }]]), id = 18
> # 2
> SELECT SUBSTR('123456789', '1')}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', 1:BIGINT)]), id = 41
> IgniteValues(tuples=[[{ 0 }]]), id = 39
> {code}
> # 3
> SELECT SUBSTR(''::UUID, 1)}
> IgniteProject(EXPR$0=[SUBSTR(CAST(_UTF-8''):UUID NOT NULL, 1)]), id = 83
> IgniteValues(tuples=[[{ 0 }]]), id = 81
> # 4
> SELECT SUBSTR('123456789', ?, 1)
> Dynamic parameters: [---- ]
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', ?0, 1)]), id = 104
> IgniteValues(tuples=[[{ 0 }]]), id = 102
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19469) Sql. Functions. Type coercion of function arguments (SUBSTR function).
[
https://issues.apache.org/jira/browse/IGNITE-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875218#comment-17875218
]
Pavel Pereslegin commented on IGNITE-19469:
---
I think the same applies to {{LENGTH()}}.
In the AI3 the following query works fine
{code:java}
SELECT LENGTH(1234)
{code}
But should produce a validation error
> Sql. Functions. Type coercion of function arguments (SUBSTR function).
> --
>
> Key: IGNITE-19469
> URL: https://issues.apache.org/jira/browse/IGNITE-19469
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> Calls to SUBSTR function with arguments of not compatible types does not
> cause validation errors in some cases:
> {code:java}
> # 1
> SELECT SUBSTR(100, 1)}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'100':VARCHAR CHARACTER SET "UTF-8", 1)]),
> id = 20
> IgniteValues(tuples=[[{ 0 }]]), id = 18
> # 2
> SELECT SUBSTR('123456789', '1')}
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', 1:BIGINT)]), id = 41
> IgniteValues(tuples=[[{ 0 }]]), id = 39
> {code}
> # 3
> SELECT SUBSTR(''::UUID, 1)}
> IgniteProject(EXPR$0=[SUBSTR(CAST(_UTF-8''):UUID NOT NULL, 1)]), id = 83
> IgniteValues(tuples=[[{ 0 }]]), id = 81
> # 4
> SELECT SUBSTR('123456789', ?, 1)
> Dynamic parameters: [---- ]
> IgniteProject(EXPR$0=[SUBSTR(_UTF-8'123456789', ?0, 1)]), id = 104
> IgniteValues(tuples=[[{ 0 }]]), id = 102
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22779) Sql. Exception on insert with dyn params when type doesn't match
[
https://issues.apache.org/jira/browse/IGNITE-22779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22779:
-
Assignee: Pavel Pereslegin
> Sql. Exception on insert with dyn params when type doesn't match
>
>
> Key: IGNITE-22779
> URL: https://issues.apache.org/jira/browse/IGNITE-22779
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> An insert statement with dynamic params fails with weird {{Values passed to
> VALUES operator must have compatible types}} when parameter doesn't exactly
> match type of the column in table. Similar query but with literal work as a
> charm, as well as insert from source table, thus I would expect the case with
> dyn params work as well.
> There is a test disabled with this ticket
> (org.apache.ignite.internal.sql.engine.ItCastToTsWithLocalTimeZoneTest#implicitCastOfDynParamsOnInsert).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22779) Sql. Exception on insert with dyn params when type doesn't match
[
https://issues.apache.org/jira/browse/IGNITE-22779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22779:
-
Assignee: (was: Pavel Pereslegin)
> Sql. Exception on insert with dyn params when type doesn't match
>
>
> Key: IGNITE-22779
> URL: https://issues.apache.org/jira/browse/IGNITE-22779
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> An insert statement with dynamic params fails with weird {{Values passed to
> VALUES operator must have compatible types}} when parameter doesn't exactly
> match type of the column in table. Similar query but with literal work as a
> charm, as well as insert from source table, thus I would expect the case with
> dyn params work as well.
> There is a test disabled with this ticket
> (org.apache.ignite.internal.sql.engine.ItCastToTsWithLocalTimeZoneTest#implicitCastOfDynParamsOnInsert).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22779) Sql. Exception on insert with dyn params when type doesn't match
[
https://issues.apache.org/jira/browse/IGNITE-22779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22779:
-
Assignee: Pavel Pereslegin
> Sql. Exception on insert with dyn params when type doesn't match
>
>
> Key: IGNITE-22779
> URL: https://issues.apache.org/jira/browse/IGNITE-22779
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> An insert statement with dynamic params fails with weird {{Values passed to
> VALUES operator must have compatible types}} when parameter doesn't exactly
> match type of the column in table. Similar query but with literal work as a
> charm, as well as insert from source table, thus I would expect the case with
> dyn params work as well.
> There is a test disabled with this ticket
> (org.apache.ignite.internal.sql.engine.ItCastToTsWithLocalTimeZoneTest#implicitCastOfDynParamsOnInsert).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22975) Catalog compaction. Improve minimum tx begin time local determination
[
https://issues.apache.org/jira/browse/IGNITE-22975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22975:
--
Description:
Currently minimum begin time among all transactions started locally computes
under write lock.
{code:java}
@Override
public HybridTimestamp minimumBeginTime(Supplier
defaultBeginTime) {
readWriteLock.writeLock().lock();
try {
return txCatalogVersionByBeginTxTs.keySet().stream()
.min(HybridTimestamp::compareTo)
.orElse(defaultBeginTime.get());
} finally {
readWriteLock.writeLock().unlock();
}
}
{code}
This code blocks the start of transactions and can be optimized.
Need to investigate possible ways to optimize it.
* may be we can somehow use existing ordered map {{txCountByCatalogVersion}} to
provide minimum require catalog version instead of tx begin time and
rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
* may be we can use {{lowWatermark.current()}} instead of current time
p.s. original discussion link
https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
was:
Currently minimum begin time among all transactions started locally computes
under write lock.
{code:java}
@Override
public HybridTimestamp minimumBeginTime(Supplier
defaultBeginTime) {
readWriteLock.writeLock().lock();
try {
return txCatalogVersionByBeginTxTs.keySet().stream()
.min(HybridTimestamp::compareTo)
.orElse(defaultBeginTime.get());
} finally {
readWriteLock.writeLock().unlock();
}
}
{code}
This code blocks the start of transactions and can be optimized.
Need to investigate possible ways to optimize it.
* may be we can somehow use existing ordered map {{txCountByCatalogVersion}} to
provide minimum require catalog version instead of tx begin time and
rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
* alternatively we can use {{lowWatermark.current()}} instead of current time
and remove write lock.
p.s. original discussion link
https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
> Catalog compaction. Improve minimum tx begin time local determination
> -
>
> Key: IGNITE-22975
> URL: https://issues.apache.org/jira/browse/IGNITE-22975
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently minimum begin time among all transactions started locally computes
> under write lock.
> {code:java}
> @Override
> public HybridTimestamp minimumBeginTime(Supplier
> defaultBeginTime) {
> readWriteLock.writeLock().lock();
> try {
> return txCatalogVersionByBeginTxTs.keySet().stream()
> .min(HybridTimestamp::compareTo)
> .orElse(defaultBeginTime.get());
> } finally {
> readWriteLock.writeLock().unlock();
> }
> }
> {code}
> This code blocks the start of transactions and can be optimized.
> Need to investigate possible ways to optimize it.
> * may be we can somehow use existing ordered map {{txCountByCatalogVersion}}
> to provide minimum require catalog version instead of tx begin time and
> rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
> * may be we can use {{lowWatermark.current()}} instead of current time
> p.s. original discussion link
> https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22975) Catalog compaction. Improve minimum tx begin time local determination
[
https://issues.apache.org/jira/browse/IGNITE-22975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22975:
--
Description:
Currently minimum begin time among all transactions started locally computes
under write lock.
{code:java}
@Override
public HybridTimestamp minimumBeginTime(Supplier
defaultBeginTime) {
readWriteLock.writeLock().lock();
try {
return txCatalogVersionByBeginTxTs.keySet().stream()
.min(HybridTimestamp::compareTo)
.orElse(defaultBeginTime.get());
} finally {
readWriteLock.writeLock().unlock();
}
}
{code}
This code blocks the start of transactions and can be optimized.
Need to investigate possible ways to optimize it.
* may be we can somehow use existing ordered map {{txCountByCatalogVersion}} to
provide minimum require catalog version instead of tx begin time and
rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
* alternatively we can use {{lowWatermark.current()}} instead of current time
and remove write lock.
p.s. original discussion link
https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
was:
Currently minimum begin time among all transactions started locally computes
under write lock.
{code:java}
@Override
public HybridTimestamp minimumBeginTime(Supplier
defaultBeginTime) {
readWriteLock.writeLock().lock();
try {
return txCatalogVersionByBeginTxTs.keySet().stream()
.min(HybridTimestamp::compareTo)
.orElse(defaultBeginTime.get());
} finally {
readWriteLock.writeLock().unlock();
}
}
{code}
This code blocks the start of transactions and can be optimized.
Need to investigate possible ways to optimize it.
* may be we can somehow use existing ordered map {{txCountByCatalogVersion}} to
provide minimum require catalog version instead of tx begin time and
rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
* may be we can ignore defaultBeginTime supplier and not update this timestamp
when there are no active RW transactions.
p.s. original discussion link
https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
> Catalog compaction. Improve minimum tx begin time local determination
> -
>
> Key: IGNITE-22975
> URL: https://issues.apache.org/jira/browse/IGNITE-22975
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently minimum begin time among all transactions started locally computes
> under write lock.
> {code:java}
> @Override
> public HybridTimestamp minimumBeginTime(Supplier
> defaultBeginTime) {
> readWriteLock.writeLock().lock();
> try {
> return txCatalogVersionByBeginTxTs.keySet().stream()
> .min(HybridTimestamp::compareTo)
> .orElse(defaultBeginTime.get());
> } finally {
> readWriteLock.writeLock().unlock();
> }
> }
> {code}
> This code blocks the start of transactions and can be optimized.
> Need to investigate possible ways to optimize it.
> * may be we can somehow use existing ordered map {{txCountByCatalogVersion}}
> to provide minimum require catalog version instead of tx begin time and
> rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
> * alternatively we can use {{lowWatermark.current()}} instead of current time
> and remove write lock.
> p.s. original discussion link
> https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22975) Catalog compaction. Improve minimum tx begin time local determination
[
https://issues.apache.org/jira/browse/IGNITE-22975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22975:
--
Description:
Currently minimum begin time among all transactions started locally computes
under write lock.
{code:java}
@Override
public HybridTimestamp minimumBeginTime(Supplier
defaultBeginTime) {
readWriteLock.writeLock().lock();
try {
return txCatalogVersionByBeginTxTs.keySet().stream()
.min(HybridTimestamp::compareTo)
.orElse(defaultBeginTime.get());
} finally {
readWriteLock.writeLock().unlock();
}
}
{code}
This code blocks the start of transactions and can be optimized.
Need to investigate possible ways to optimize it.
* may be we can somehow use existing ordered map {{txCountByCatalogVersion}} to
provide minimum require catalog version instead of tx begin time and
rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
* may be we can ignore defaultBeginTime supplier and not update this timestamp
when there are no active RW transactions.
p.s. original discussion link
https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
was:
Currently minimum begin time among all transactions started locally computes
under write lock.
{code:java}
@Override
public HybridTimestamp minimumBeginTime(Supplier
defaultBeginTime) {
readWriteLock.writeLock().lock();
try {
return txCatalogVersionByBeginTxTs.keySet().stream()
.min(HybridTimestamp::compareTo)
.orElse(defaultBeginTime.get());
} finally {
readWriteLock.writeLock().unlock();
}
}
{code}
This code blocks the start of transactions and can be optimized.
Need to investigate possible ways to optimize it.
* may be we can somehow use existing ordered map {{txCountByCatalogVersion}} to
provide minimum require catalog version instead of tx begin time and
rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
* may be we can ignore defaultBeginTime supplier and not update this timestamp
when there are no active RW transactions.
> Catalog compaction. Improve minimum tx begin time local determination
> -
>
> Key: IGNITE-22975
> URL: https://issues.apache.org/jira/browse/IGNITE-22975
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently minimum begin time among all transactions started locally computes
> under write lock.
> {code:java}
> @Override
> public HybridTimestamp minimumBeginTime(Supplier
> defaultBeginTime) {
> readWriteLock.writeLock().lock();
> try {
> return txCatalogVersionByBeginTxTs.keySet().stream()
> .min(HybridTimestamp::compareTo)
> .orElse(defaultBeginTime.get());
> } finally {
> readWriteLock.writeLock().unlock();
> }
> }
> {code}
> This code blocks the start of transactions and can be optimized.
> Need to investigate possible ways to optimize it.
> * may be we can somehow use existing ordered map {{txCountByCatalogVersion}}
> to provide minimum require catalog version instead of tx begin time and
> rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
> * may be we can ignore defaultBeginTime supplier and not update this
> timestamp when there are no active RW transactions.
> p.s. original discussion link
> https://github.com/apache/ignite-3/pull/4137#discussion_r1705728506
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22951) Catalog compaction. Improve minimum tx begin time propagation to replicas
[
https://issues.apache.org/jira/browse/IGNITE-22951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874800#comment-17874800
]
Pavel Pereslegin commented on IGNITE-22951:
---
[~alapin], [~korlov],
review the proposed changes, please.
> Catalog compaction. Improve minimum tx begin time propagation to replicas
> -
>
> Key: IGNITE-22951
> URL: https://issues.apache.org/jira/browse/IGNITE-22951
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-22641, for each catalog compaction run we have a {{N x M}}
> replica requests, where N - count of tables, M - count of partitions.
> This looks extremely inefficient and we should consider using:
> * Message coalescing.
> * Depending on whether you actually need compaction coordinator or it's
> possible to trigger minBeginTxTime on all nodes consider sending requests to
> self only.
> * Adding some randomization on sending requests between replication groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22951) Catalog compaction. Improve minimum tx begin time propagation to replicas
[
https://issues.apache.org/jira/browse/IGNITE-22951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22951:
--
Description:
After IGNITE-22641, for each catalog compaction run we have a {{N x M}} replica
requests, where N - count of tables, M - count of partitions.
This looks extremely inefficient and we should consider using:
* Message coalescing.
* Depending on whether you actually need compaction coordinator or it's
possible to trigger minBeginTxTime on all nodes consider sending requests to
self only.
* Adding some randomization on sending requests between replication groups.
was:
After IGNITE-22641, for each catalog compaction run we have a {{N x M}} replica
requests, where N - count of tables, M - count of partitions.
This looks extremely inefficient and we should consider using:
* Message coalescing.
* Depending on whether you actually need compaction coordinator or it's
possible to trigger minStarTime on all nodes consider sending requests to self
only.
* Adding some randomization on sending requests between replication groups.
> Catalog compaction. Improve minimum tx begin time propagation to replicas
> -
>
> Key: IGNITE-22951
> URL: https://issues.apache.org/jira/browse/IGNITE-22951
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Critical
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-22641, for each catalog compaction run we have a {{N x M}}
> replica requests, where N - count of tables, M - count of partitions.
> This looks extremely inefficient and we should consider using:
> * Message coalescing.
> * Depending on whether you actually need compaction coordinator or it's
> possible to trigger minBeginTxTime on all nodes consider sending requests to
> self only.
> * Adding some randomization on sending requests between replication groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22866) Support WITH RECURSIVE ... AS
[
https://issues.apache.org/jira/browse/IGNITE-22866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22866:
--
Description:
*Description:*
Need to support recursive queries.
The query
{code:java}
WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 100)
SELECT sum(n) FROM t; {code}
should return
{code:java}
5050 {code}
currently returns error
{noformat}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:c2961dbf-64fd-4806-a2d9-20368f8454e5 There are not enough rules to
produce a node with desired properties: convention=IGNITE, distr=single,
sort=[].
Missing conversions are LogicalRepeatUnion[convention: NONE -> IGNITE, distr:
any -> single], LogicalRepeatUnion[convention: NONE -> IGNITE, distr: any ->
random]
There are 2 empty subsets:
Empty subset 0: rel#92:RelSubset#6.IGNITE.single.[], the relevant part of the
original plan is as follows
87:LogicalRepeatUnion(all=[true])
78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1 }]])
85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)])
81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
condition=[<($0, 100)])
2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]], table=[[T]])
...
(part of the debug error output was cut off)
{noformat}
was:
*Description:*
Need to support recursive queries.
The query
{code:java}
WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 100)
SELECT sum(n) FROM t; {code}
should return
{code:java}
5050 {code}
currently returns error
{noformat}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:c2961dbf-64fd-4806-a2d9-20368f8454e5 There are not enough rules to
produce a node with desired properties: convention=IGNITE, distr=single,
sort=[].
Missing conversions are LogicalRepeatUnion[convention: NONE -> IGNITE, distr:
any -> single], LogicalRepeatUnion[convention: NONE -> IGNITE, distr: any ->
random]
There are 2 empty subsets:
Empty subset 0: rel#92:RelSubset#6.IGNITE.single.[], the relevant part of the
original plan is as follows
87:LogicalRepeatUnion(all=[true])
78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1 }]])
85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)])
81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
condition=[<($0, 100)])
2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]], table=[[T]])
...
(part of the debug error output was cut out)
{noformat}
> Support WITH RECURSIVE ... AS
> -
>
> Key: IGNITE-22866
> URL: https://issues.apache.org/jira/browse/IGNITE-22866
> Project: Ignite
> Issue Type: Improvement
> Components: general, sql
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
>
> *Description:*
> Need to support recursive queries.
> The query
> {code:java}
> WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 100)
> SELECT sum(n) FROM t; {code}
> should return
> {code:java}
> 5050 {code}
> currently returns error
> {noformat}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:c2961dbf-64fd-4806-a2d9-20368f8454e5 There are not enough rules to
> produce a node with desired properties: convention=IGNITE, distr=single,
> sort=[].
> Missing conversions are LogicalRepeatUnion[convention: NONE -> IGNITE, distr:
> any -> single], LogicalRepeatUnion[convention: NONE -> IGNITE, distr: any ->
> random]
> There are 2 empty subsets:
> Empty subset 0: rel#92:RelSubset#6.IGNITE.single.[], the relevant part of the
> original plan is as follows
> 87:LogicalRepeatUnion(all=[true])
> 78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
> readType=[LAZY], writeType=[LAZY], table=[[T]])
> 1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1
> }]])
> 85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
> readType=[LAZY], writeType=[LAZY], table=[[T]])
> 83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
> 1)])
> 81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
> condition=[<($0, 100)])
> 2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]],
> table=[[T]])
> ...
> (part of the debug error output was cut off)
> {noformat}
--
This message was sent
[jira] [Updated] (IGNITE-22873) InvalidTypeException should not include a value in its error message
[
https://issues.apache.org/jira/browse/IGNITE-22873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22873:
--
Fix Version/s: 3.0.0-beta2
> InvalidTypeException should not include a value in its error message
>
>
> Key: IGNITE-22873
> URL: https://issues.apache.org/jira/browse/IGNITE-22873
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> 1. Create a table (int, string).
> 2. Attempt to write a multi megabyte string.
> 3. Error is not returned immediately.
> This happens because Column::validate includes a value that caused a
> validation error into a message.
> Example:
> {noformat}
> @Test
> public void test() {
> igniteSql().execute(null, "CREATE TABLE t (id INT PRIMARY KEY, data
> VARCHAR)").close();
> Table table = table("T");
> KeyValueView kv = table.keyValueView();
> String s = "a".repeat(50*1024*1024);
> kv.put(null, Tuple.create().set("id", 1), Tuple.create().set("data",
> s));
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22951) Catalog compaction. Improve minimum tx begin time propagation to replicas
[
https://issues.apache.org/jira/browse/IGNITE-22951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-22951:
-
Assignee: Pavel Pereslegin
> Catalog compaction. Improve minimum tx begin time propagation to replicas
> -
>
> Key: IGNITE-22951
> URL: https://issues.apache.org/jira/browse/IGNITE-22951
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Critical
> Labels: ignite-3
>
> After IGNITE-22641, for each catalog compaction run we have a {{N x M}}
> replica requests, where N - count of tables, M - count of partitions.
> This looks extremely inefficient and we should consider using:
> * Message coalescing.
> * Depending on whether you actually need compaction coordinator or it's
> possible to trigger minStarTime on all nodes consider sending requests to
> self only.
> * Adding some randomization on sending requests between replication groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22975) Catalog compaction. Improve minimum tx begin time local computation
[
https://issues.apache.org/jira/browse/IGNITE-22975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22975:
--
Summary: Catalog compaction. Improve minimum tx begin time local
computation (was: Catalog compaction. Improve minimum tx begin time
computation)
> Catalog compaction. Improve minimum tx begin time local computation
> ---
>
> Key: IGNITE-22975
> URL: https://issues.apache.org/jira/browse/IGNITE-22975
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>
> Currently minimum begin time among all transactions started locally computes
> under write lock.
> {code:java}
> @Override
> public HybridTimestamp minimumBeginTime(Supplier
> defaultBeginTime) {
> readWriteLock.writeLock().lock();
> try {
> return txCatalogVersionByBeginTxTs.keySet().stream()
> .min(HybridTimestamp::compareTo)
> .orElse(defaultBeginTime.get());
> } finally {
> readWriteLock.writeLock().unlock();
> }
> }
> {code}
> This code blocks the start of transactions and can be optimized.
> Need to investigate possible ways to optimize it.
> * may be we can somehow use existing ordered map {{txCountByCatalogVersion}}
> to provide minimum require catalog version instead of tx begin time and
> rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
> * may be we can ignore defaultBeginTime supplier and not update this
> timestamp when there are no active RW transactions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22975) Catalog compaction. Improve minimum tx begin time local determination
[
https://issues.apache.org/jira/browse/IGNITE-22975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22975:
--
Summary: Catalog compaction. Improve minimum tx begin time local
determination (was: Catalog compaction. Improve minimum tx begin time local
computation)
> Catalog compaction. Improve minimum tx begin time local determination
> -
>
> Key: IGNITE-22975
> URL: https://issues.apache.org/jira/browse/IGNITE-22975
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>
> Currently minimum begin time among all transactions started locally computes
> under write lock.
> {code:java}
> @Override
> public HybridTimestamp minimumBeginTime(Supplier
> defaultBeginTime) {
> readWriteLock.writeLock().lock();
> try {
> return txCatalogVersionByBeginTxTs.keySet().stream()
> .min(HybridTimestamp::compareTo)
> .orElse(defaultBeginTime.get());
> } finally {
> readWriteLock.writeLock().unlock();
> }
> }
> {code}
> This code blocks the start of transactions and can be optimized.
> Need to investigate possible ways to optimize it.
> * may be we can somehow use existing ordered map {{txCountByCatalogVersion}}
> to provide minimum require catalog version instead of tx begin time and
> rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
> * may be we can ignore defaultBeginTime supplier and not update this
> timestamp when there are no active RW transactions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22975) Catalog compaction. Improve minimum tx begin time computation
Pavel Pereslegin created IGNITE-22975:
-
Summary: Catalog compaction. Improve minimum tx begin time
computation
Key: IGNITE-22975
URL: https://issues.apache.org/jira/browse/IGNITE-22975
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Pereslegin
Currently minimum begin time among all transactions started locally computes
under write lock.
{code:java}
@Override
public HybridTimestamp minimumBeginTime(Supplier
defaultBeginTime) {
readWriteLock.writeLock().lock();
try {
return txCatalogVersionByBeginTxTs.keySet().stream()
.min(HybridTimestamp::compareTo)
.orElse(defaultBeginTime.get());
} finally {
readWriteLock.writeLock().unlock();
}
}
{code}
This code blocks the start of transactions and can be optimized.
Need to investigate possible ways to optimize it.
* may be we can somehow use existing ordered map {{txCountByCatalogVersion}} to
provide minimum require catalog version instead of tx begin time and
rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
* may be we can ignore defaultBeginTime supplier and not update this timestamp
when there are no active RW transactions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22975) Catalog compaction. Improve minimum tx begin time computation
[
https://issues.apache.org/jira/browse/IGNITE-22975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22975:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Catalog compaction. Improve minimum tx begin time computation
> -
>
> Key: IGNITE-22975
> URL: https://issues.apache.org/jira/browse/IGNITE-22975
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>
> Currently minimum begin time among all transactions started locally computes
> under write lock.
> {code:java}
> @Override
> public HybridTimestamp minimumBeginTime(Supplier
> defaultBeginTime) {
> readWriteLock.writeLock().lock();
> try {
> return txCatalogVersionByBeginTxTs.keySet().stream()
> .min(HybridTimestamp::compareTo)
> .orElse(defaultBeginTime.get());
> } finally {
> readWriteLock.writeLock().unlock();
> }
> }
> {code}
> This code blocks the start of transactions and can be optimized.
> Need to investigate possible ways to optimize it.
> * may be we can somehow use existing ordered map {{txCountByCatalogVersion}}
> to provide minimum require catalog version instead of tx begin time and
> rework/remove {{ActiveLocalTxMinimumBeginTimeProvider}}.
> * may be we can ignore defaultBeginTime supplier and not update this
> timestamp when there are no active RW transactions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22637) Catalog compaction. Implement remote node part of compaction flow
[
https://issues.apache.org/jira/browse/IGNITE-22637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22637:
--
Description:
To select a compaction time, each node should provide its MinimalRequiredTime
to compaction coordinator.
h4. Prerequisites:
In {{PartitionListener}} using partitionDataStorage.flush(false) store
{{minActiveTxBeginTime}} into another transient field (for example
{{snapshottedMinActiveTxBeginTime}}).
Need to investigate how to obtain this {{snapshottedMinActiveTxBeginTime}} from
{{CatalogCompactionRunner}} in production code (may be introduce necessary
methods). Example of this in test code can be found in
{{ItCatalogCompactionTest.ensureTimestampStoredInAllReplicas}}
h4. Compute minimum required time
1. Get current value of low watermark.
2. Get min of "snapshotted" minActiveTxTime across all partitions (see
{{PartitionListener.minActiveTxBeginTime}}.
Take min of 1., 2 and return it in
{{CatalogCompactionRunner.determineLocalMinimumRequiredTime}}
h4. Additional notes
Compaction must start only under the following conditions:
1. no active builds of indexes -- check for indexes are done on coordinator node
2. no active rebalance referring an old versions -- rebalance started with the
latest version
Depending on the complexity, the last part may be implemented as a separate
ticket, but compaction should not be enabled until all parts are implemented.
was:
To select a compaction time, each node should provide its MinimalRequiredTime
to compaction coordinator.
h4. Prerequisites:
In {{PartitionListener}} using partitionDataStorage.flush(false) store
{{minActiveTxBeginTime}} into another transient field (for example
{{snapshottedMinActiveTxBeginTime}}).
Need to investigate how to obtain this {{snapshottedMinActiveTxBeginTime}} from
{{CatalogCompactionRunner}} in production code (may be introduce necessary
methods). Example of this in test code can be found in
{{ItCatalogCompactionTest.ensureTimestampStoredInAllReplicas}}
h4. Compute minimum required time
1. Get current value of low watermark.
2. Get min of "snapshotted" minActiveTxTime across all partitions (see
{{PartitionListener.minActiveTxBeginTime}}.
Take min of 1., 2
h4.
> Catalog compaction. Implement remote node part of compaction flow
> -
>
> Key: IGNITE-22637
> URL: https://issues.apache.org/jira/browse/IGNITE-22637
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> To select a compaction time, each node should provide its MinimalRequiredTime
> to compaction coordinator.
> h4. Prerequisites:
> In {{PartitionListener}} using partitionDataStorage.flush(false) store
> {{minActiveTxBeginTime}} into another transient field (for example
> {{snapshottedMinActiveTxBeginTime}}).
> Need to investigate how to obtain this {{snapshottedMinActiveTxBeginTime}}
> from {{CatalogCompactionRunner}} in production code (may be introduce
> necessary methods). Example of this in test code can be found in
> {{ItCatalogCompactionTest.ensureTimestampStoredInAllReplicas}}
> h4. Compute minimum required time
> 1. Get current value of low watermark.
> 2. Get min of "snapshotted" minActiveTxTime across all partitions (see
> {{PartitionListener.minActiveTxBeginTime}}.
> Take min of 1., 2 and return it in
> {{CatalogCompactionRunner.determineLocalMinimumRequiredTime}}
> h4. Additional notes
> Compaction must start only under the following conditions:
> 1. no active builds of indexes -- check for indexes are done on coordinator
> node
> 2. no active rebalance referring an old versions -- rebalance started with
> the latest version
> Depending on the complexity, the last part may be implemented as a separate
> ticket, but compaction should not be enabled until all parts are implemented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22637) Catalog compaction. Implement remote node part of compaction flow
[
https://issues.apache.org/jira/browse/IGNITE-22637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22637:
--
Description:
To select a compaction time, each node should provide its MinimalRequiredTime
to compaction coordinator.
h4. Prerequisites:
In {{PartitionListener}} using partitionDataStorage.flush(false) store
{{minActiveTxBeginTime}} into another transient field (for example
{{snapshottedMinActiveTxBeginTime}}).
Need to investigate how to obtain this {{snapshottedMinActiveTxBeginTime}} from
{{CatalogCompactionRunner}} in production code (may be introduce necessary
methods). Example of this in test code can be found in
{{ItCatalogCompactionTest.ensureTimestampStoredInAllReplicas}}
h4. Compute minimum required time
1. Get current value of low watermark.
2. Get min of "snapshotted" minActiveTxTime across all partitions (see
{{PartitionListener.minActiveTxBeginTime}}.
Take min of 1., 2
h4.
was:
To select a compaction time, each node should provide its MinimalRequiredTime
to compaction coordinator. To compute that time:
1. Get current value of low watermark.
2. Get min of check pointed time across all partitions.
3. Get min of begin_time across all started transaction.
4. Take min of 1., 2., 3.
begin_time transaction time (3) is stored in transient state of the
PartitionListener.
During checkpoint we write that time into the raft log.
When the compaction coordinator chooses min catalog version/catalog time, it
sends a catalog compaction command with this information to each node. Each
node should execute such command to perform compaction.
> Catalog compaction. Implement remote node part of compaction flow
> -
>
> Key: IGNITE-22637
> URL: https://issues.apache.org/jira/browse/IGNITE-22637
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> To select a compaction time, each node should provide its MinimalRequiredTime
> to compaction coordinator.
> h4. Prerequisites:
> In {{PartitionListener}} using partitionDataStorage.flush(false) store
> {{minActiveTxBeginTime}} into another transient field (for example
> {{snapshottedMinActiveTxBeginTime}}).
> Need to investigate how to obtain this {{snapshottedMinActiveTxBeginTime}}
> from {{CatalogCompactionRunner}} in production code (may be introduce
> necessary methods). Example of this in test code can be found in
> {{ItCatalogCompactionTest.ensureTimestampStoredInAllReplicas}}
> h4. Compute minimum required time
> 1. Get current value of low watermark.
> 2. Get min of "snapshotted" minActiveTxTime across all partitions (see
> {{PartitionListener.minActiveTxBeginTime}}.
> Take min of 1., 2
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22635) Sql. Unable to optimize plan error for input out of range
[
https://issues.apache.org/jira/browse/IGNITE-22635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22635:
--
Fix Version/s: 3.0.0-beta2
> Sql. Unable to optimize plan error for input out of range
> -
>
> Key: IGNITE-22635
> URL: https://issues.apache.org/jira/browse/IGNITE-22635
> 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: 2h 10m
> Remaining Estimate: 0h
>
> In some cases, we can't make a query plan in case input values is out of
> range of destination.
> For example:
> {code:java}
> @Test
> public void test() {
> sql("CREATE TABLE TEST(ID TINYINT PRIMARY KEY, VAL0 TINYINT)");
> long a = Long.MAX_VALUE-1000;
> BigDecimal val = BigDecimal.valueOf(a + ((double) a /
> 1000)).add(BigDecimal.valueOf(Long.MAX_VALUE));
> igniteSql().execute(null, "INSERT INTO TEST VALUES (" + val + ", " + val +
> ")");
> }{code}
> —
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:15fcd9d1-e906-418d-95c5-b5cbde5fb6eb Unable to optimize plan due to
> internal error
> at
> org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:166)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:405)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:393)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.physicalPlan(AbstractPlannerTest.java:377)
> at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.assertPlan(AbstractPlannerTest.java:499)
>at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.assertPlan(AbstractPlannerTest.java:488)
>at
> org.apache.ignite.internal.sql.engine.planner.AbstractPlannerTest.assertPlan(AbstractPlannerTest.java:469)
>at
> org.apache.ignite.internal.sql.engine.planner.datatypes.NumericInsertSourcesCoercionTest.insert1(NumericInsertSourcesCoercionTest.java:94)
>at java.base/java.lang.reflect.Method.invoke(Method.java:580) at
> java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at
> java.base/java.util.ArrayList.forEach(ArrayList.java:1596)Caused by:
> java.lang.ArithmeticException: BIGINT out of range at
> org.apache.ignite.internal.sql.engine.util.IgniteMath.checkNumberLongBounds(IgniteMath.java:486)
> at
> org.apache.ignite.internal.sql.engine.util.IgniteMath.convertToLongExact(IgniteMath.java:292)
> at
> org.apache.ignite.internal.sql.engine.util.Primitives.convertPrimitiveExact(Primitives.java:127)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateLiteral(RexToLixTranslator.java:916)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLiteral(RexToLixTranslator.java:1164)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLiteral(RexToLixTranslator.java:113)
> at org.apache.calcite.rex.RexLiteral.accept(RexLiteral.java:1251) at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1142)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77) at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.implementCallOperand(RexToLixTranslator.java:1275)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:1262)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitCall(RexToLixTranslator.java:113)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189) at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:1142)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.visitLocalRef(RexToLixTranslator.java:113)
> at org.apache.calcite.rex.RexLocalRef.accept(RexLocalRef.java:77) at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:274)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translate(RexToLixTranslator.java:268)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateList(RexToLixTranslator.java:982)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.RexToLixTranslator.translateProjects(RexToLixTranslator.java:222)
> at
> org.apache.ignite.interna
[jira] [Updated] (IGNITE-22951) Catalog compaction. Improve minimum tx begin time propagation to replicas
[
https://issues.apache.org/jira/browse/IGNITE-22951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22951:
--
Priority: Critical (was: Major)
> Catalog compaction. Improve minimum tx begin time propagation to replicas
> -
>
> Key: IGNITE-22951
> URL: https://issues.apache.org/jira/browse/IGNITE-22951
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Critical
> Labels: ignite-3
>
> After IGNITE-22641, for each catalog compaction run we have a {{N x M}}
> replica requests, where N - count of tables, M - count of partitions.
> This looks extremely inefficient and we should consider using:
> * Message coalescing.
> * Depending on whether you actually need compaction coordinator or it's
> possible to trigger minStarTime on all nodes consider sending requests to
> self only.
> * Adding some randomization on sending requests between replication groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22757) Excessive memory usage in schema-related code in SQL
[
https://issues.apache.org/jira/browse/IGNITE-22757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22757:
--
Fix Version/s: 3.0.0-beta2
> Excessive memory usage in schema-related code in SQL
>
>
> Key: IGNITE-22757
> URL: https://issues.apache.org/jira/browse/IGNITE-22757
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Roman Puchkovskiy
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: image-2024-07-17-14-13-29-683.png
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I have the following test:
>
> {noformat}
> class It1000TablesTest extends ClusterPerTestIntegrationTest {
> private static final String DEFAULT_STORAGE_ENGINE = "";
> private final String storageEngine = "aipersist";
> private final int columnsCount = 200;
> @Override
> protected int initialNodes() {
> return 1;
> }
> @Test
> void test() {
> String storageProfile =
> DEFAULT_STORAGE_ENGINE.equals(storageEngine) ?
> DEFAULT_STORAGE_PROFILE : "default_" + storageEngine.toLowerCase();
> String zoneSql = "create zone test_zone with replicas=1,
> storage_profiles='" + storageProfile + "';";
> cluster.doInSession(0, session -> {
> executeUpdate(zoneSql, session);
> });
> for (int i = 0; i < 1000; i++) {
> String tableName = String.format("table%03d", i);
> String valColumns = columnNames()
> .map(colName -> colName + " varchar(40)")
> .collect(joining(", "));
> String tableSql = "create table " + tableName + " (key int
> primary key, " + valColumns + ")"
> + " with primary_zone='TEST_ZONE', storage_profile='" +
> storageProfile + "';";
> String columnNames = columnNames().collect(joining(", "));
> String values = IntStream.range(0, columnsCount)
> .mapToObj(n -> UUID.randomUUID().toString())
> .map(s -> "'" + s + "'")
> .collect(joining(", "));
> String insertSql = "insert into " + tableName + " (key, " +
> columnNames + ") values (" + i + ", " + values + ")";
> cluster.doInSession(0, session -> {
> executeUpdate(tableSql, session);
> executeUpdate(insertSql, session);
> });
> int createdTables = i + 1;
> if (createdTables % 1 == 0) {
> log.info("XXX Created " + createdTables + " tables");
> }
> }
> }
> private Stream columnNames() {
> return IntStream.range(0, columnsCount)
> .mapToObj(n -> String.format("val%03d", n));
> }
> }
> {noformat}
> It just tries to create a 1000 of tables, 201 column each (sharing the same
> zone), making an insert to each of them after creating it.
>
> After creating about 200 tables I took a heap dump, here are the top
> consumers of the heap:
> !image-2024-07-17-14-13-29-683.png!
> There are just around tables, but 20k IgniteTableImpl instances and more than
> 4M CatalogColumnDescriptor instances. It feels like an arithmetic
> progression: sum of 1..200 gives (1+200)*100≈2, as if addition of a new
> table made a copy of all existing tables as well.
> SqlSchemaManager caches tables by pair, so, if a
> catalog is modified N times in a way that does not concern a table, N copies
> of the table might be created in the cache (and they do get created). It
> seems natural to cache tables (maybe additionally to the existing caching) by
> .
> Another problem is that, as the cache is bounded, it starts forgetting older
> instances, so they get recreated; but those older instances are actually used
> by some internal structures of Calcite, so, even if tables are properly
> cached by , duplicates will emerge when anough tables
> are created.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22951) Catalog compaction. Improve minimum tx begin time propagation to replicas
Pavel Pereslegin created IGNITE-22951:
-
Summary: Catalog compaction. Improve minimum tx begin time
propagation to replicas
Key: IGNITE-22951
URL: https://issues.apache.org/jira/browse/IGNITE-22951
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Pavel Pereslegin
After IGNITE-22641, for each catalog compaction run we have a {{N x M}} replica
requests, where N - count of tables, M - count of partitions.
This looks extremely inefficient and we should consider using:
* Message coalescing.
* Depending on whether you actually need compaction coordinator or it's
possible to trigger minStarTime on all nodes consider sending requests to self
only.
* Adding some randomization on sending requests between replication groups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22945) Remove duplicate method from CatalogTableDescriptor
[
https://issues.apache.org/jira/browse/IGNITE-22945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22945:
--
Labels: ignite-3 newbie (was: ignite-3)
> Remove duplicate method from CatalogTableDescriptor
> ---
>
> Key: IGNITE-22945
> URL: https://issues.apache.org/jira/browse/IGNITE-22945
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Minor
> Labels: ignite-3, newbie
>
> {{CatalogTableDescriptor}} has two identical methods to get a
> {{CatalogTableColumnDescriptor}} by column name.
> {code:java}
> public CatalogTableColumnDescriptor column(String name)
> public CatalogTableColumnDescriptor columnDescriptor(String columnName)
> {code}
> Need to remove one of them.
> Personally, I prefer to get rid from {{columnDescriptor()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22945) Remove duplicate method from CatalogTableDescriptor
[
https://issues.apache.org/jira/browse/IGNITE-22945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22945:
--
Labels: ignite-3 (was: ignite-3 newbe)
> Remove duplicate method from CatalogTableDescriptor
> ---
>
> Key: IGNITE-22945
> URL: https://issues.apache.org/jira/browse/IGNITE-22945
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Minor
> Labels: ignite-3
>
> {{CatalogTableDescriptor}} has two identical methods to get a
> {{CatalogTableColumnDescriptor}} by column name.
> {code:java}
> public CatalogTableColumnDescriptor column(String name)
> public CatalogTableColumnDescriptor columnDescriptor(String columnName)
> {code}
> Need to remove one of them.
> Personally, I prefer to get rid from {{columnDescriptor()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22945) Remove duplicate method from CatalogTableDescriptor
Pavel Pereslegin created IGNITE-22945:
-
Summary: Remove duplicate method from CatalogTableDescriptor
Key: IGNITE-22945
URL: https://issues.apache.org/jira/browse/IGNITE-22945
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Pavel Pereslegin
{{CatalogTableDescriptor}} has two identical methods to get a
{{CatalogTableColumnDescriptor}} by column name.
{code:java}
public CatalogTableColumnDescriptor column(String name)
public CatalogTableColumnDescriptor columnDescriptor(String columnName)
{code}
Need to remove one of them.
Personally, I prefer to get rid from {{columnDescriptor()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22936) Sql. Confusing error message when trying to use recursive CTE
[
https://issues.apache.org/jira/browse/IGNITE-22936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22936:
--
Component/s: sql
> Sql. Confusing error message when trying to use recursive CTE
> -
>
> Key: IGNITE-22936
> URL: https://issues.apache.org/jira/browse/IGNITE-22936
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> We don't currently support recursive common table expressions (IGNITE-22866).
> However, the error output for such queries is huge and confusing because it
> contains debugging information.
> For example:
> {code:sql}
> WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 100)
> SELECT sum(n) FROM t;
> {code}
> Produces the following error
> {noformat}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:c2961dbf-64fd-4806-a2d9-20368f8454e5 There are not enough rules to
> produce a node with desired properties: convention=IGNITE, distr=single,
> sort=[].
> Missing conversions are LogicalRepeatUnion[convention: NONE -> IGNITE, distr:
> any -> single], LogicalRepeatUnion[convention: NONE -> IGNITE, distr: any ->
> random]
> There are 2 empty subsets:
> Empty subset 0: rel#92:RelSubset#6.IGNITE.single.[], the relevant part of the
> original plan is as follows
> 87:LogicalRepeatUnion(all=[true])
> 78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
> readType=[LAZY], writeType=[LAZY], table=[[T]])
> 1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1
> }]])
> 85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
> readType=[LAZY], writeType=[LAZY], table=[[T]])
> 83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
> 1)])
> 81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
> condition=[<($0, 100)])
> 2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]],
> table=[[T]])
> Empty subset 1: rel#102:RelSubset#6.IGNITE.random.[], the relevant part of
> the original plan is as follows
> 87:LogicalRepeatUnion(all=[true])
> 78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
> readType=[LAZY], writeType=[LAZY], table=[[T]])
> 1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1
> }]])
> 85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
> readType=[LAZY], writeType=[LAZY], table=[[T]])
> 83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
> 1)])
> 81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
> condition=[<($0, 100)])
> 2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]],
> table=[[T]])
> Root: rel#91:RelSubset#7.IGNITE.single.[]
> Original rel:
> LogicalAggregate(subset=[rel#91:RelSubset#7.IGNITE.single.[]], group=[{}],
> EXPR$0=[SUM($0)]): rowcount = 1.0, cumulative cost = IgniteCost
> [rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
> network=Infinity], id = 89
> LogicalRepeatUnion(subset=[rel#88:RelSubset#6.NONE.any.[]], all=[true]):
> rowcount = 501.0, cumulative cost = IgniteCost [rowCount=Infinity,
> cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 87
> LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
> readType=[LAZY], writeType=[LAZY], table=[[T]]): rowcount = 1.0, cumulative
> cost = IgniteCost [rowCount=Infinity, cpu=Infinity, memory=Infinity,
> io=Infinity, network=Infinity], id = 78
> LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1
> }]]): rowcount = 1.0, cumulative cost = IgniteCost [rowCount=Infinity,
> cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 1
> LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
> readType=[LAZY], writeType=[LAZY], table=[[T]]): rowcount = 50.0, cumulative
> cost = IgniteCost [rowCount=Infinity, cpu=Infinity, memory=Infinity,
> io=Infinity, network=Infinity], id = 85
> LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
> 1)]): rowcount = 50.0, cumulative cost = IgniteCost [rowCount=Infinity,
> cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 83
> LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
> condition=[<($0, 100)]): rowcount = 50.0, cumulative cost = IgniteCost
> [rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
> network=Infinity], id = 81
> LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]],
> table=[[T]]): rowcount = 100.0, cumulative cost = IgniteCost
> [rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
> network=Infinity], id = 2
> Sets:
> Set#0, type: RecordType(INTEGER EXPR$0)
> rel#77:RelSubset#0.NONE.any.[0], best=null
> rel#1:Logica
[jira] [Created] (IGNITE-22936) Sql. Confusing error message when trying to use recursive CTE
Pavel Pereslegin created IGNITE-22936:
-
Summary: Sql. Confusing error message when trying to use recursive
CTE
Key: IGNITE-22936
URL: https://issues.apache.org/jira/browse/IGNITE-22936
Project: Ignite
Issue Type: Improvement
Reporter: Pavel Pereslegin
We don't currently support recursive common table expressions (IGNITE-22866).
However, the error output for such queries is huge and confusing because it
contains debugging information.
For example:
{code:sql}
WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 100)
SELECT sum(n) FROM t;
{code}
Produces the following error
{noformat}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:c2961dbf-64fd-4806-a2d9-20368f8454e5 There are not enough rules to
produce a node with desired properties: convention=IGNITE, distr=single,
sort=[].
Missing conversions are LogicalRepeatUnion[convention: NONE -> IGNITE, distr:
any -> single], LogicalRepeatUnion[convention: NONE -> IGNITE, distr: any ->
random]
There are 2 empty subsets:
Empty subset 0: rel#92:RelSubset#6.IGNITE.single.[], the relevant part of the
original plan is as follows
87:LogicalRepeatUnion(all=[true])
78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1 }]])
85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)])
81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
condition=[<($0, 100)])
2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]], table=[[T]])
Empty subset 1: rel#102:RelSubset#6.IGNITE.random.[], the relevant part of the
original plan is as follows
87:LogicalRepeatUnion(all=[true])
78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1 }]])
85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)])
81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
condition=[<($0, 100)])
2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]], table=[[T]])
Root: rel#91:RelSubset#7.IGNITE.single.[]
Original rel:
LogicalAggregate(subset=[rel#91:RelSubset#7.IGNITE.single.[]], group=[{}],
EXPR$0=[SUM($0)]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
network=Infinity], id = 89
LogicalRepeatUnion(subset=[rel#88:RelSubset#6.NONE.any.[]], all=[true]):
rowcount = 501.0, cumulative cost = IgniteCost [rowCount=Infinity,
cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 87
LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=Infinity, cpu=Infinity, memory=Infinity,
io=Infinity, network=Infinity], id = 78
LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1
}]]): rowcount = 1.0, cumulative cost = IgniteCost [rowCount=Infinity,
cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 1
LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]], readType=[LAZY],
writeType=[LAZY], table=[[T]]): rowcount = 50.0, cumulative cost = IgniteCost
[rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
network=Infinity], id = 85
LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)]): rowcount = 50.0, cumulative cost = IgniteCost [rowCount=Infinity,
cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 83
LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]], condition=[<($0,
100)]): rowcount = 50.0, cumulative cost = IgniteCost [rowCount=Infinity,
cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 81
LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]],
table=[[T]]): rowcount = 100.0, cumulative cost = IgniteCost
[rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
network=Infinity], id = 2
Sets:
Set#0, type: RecordType(INTEGER EXPR$0)
rel#77:RelSubset#0.NONE.any.[0], best=null
rel#1:LogicalValues.NONE.any.[0](type=RecordType(INTEGER EXPR$0),tuples=[{ 1
}]), rowcount=1.0, cumulative cost=IgniteCost [rowCount=Infinity, cpu=Infinity,
memory=Infinity, io=Infinity, network=Infinity]
Set#1, type: RecordType(INTEGER EXPR$0)
rel#79:RelSubset#1.NONE.any.[0], best=null
rel#78:LogicalTableSpool.NONE.any.[0](input=RelSubset#77,readType=LAZY,writeType=LAZY,table=[T]),
rowcount=1.0, cumulative cost=IgniteCost [rowCount=Infinity, cpu=Infinity,
m
[jira] [Updated] (IGNITE-22866) Support WITH RECURSIVE ... AS
[
https://issues.apache.org/jira/browse/IGNITE-22866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22866:
--
Description:
*Description:*
Need to support recursive queries.
The query
{code:java}
WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 100)
SELECT sum(n) FROM t; {code}
should return
{code:java}
5050 {code}
currently returns error
{noformat}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:c2961dbf-64fd-4806-a2d9-20368f8454e5 There are not enough rules to
produce a node with desired properties: convention=IGNITE, distr=single,
sort=[].
Missing conversions are LogicalRepeatUnion[convention: NONE -> IGNITE, distr:
any -> single], LogicalRepeatUnion[convention: NONE -> IGNITE, distr: any ->
random]
There are 2 empty subsets:
Empty subset 0: rel#92:RelSubset#6.IGNITE.single.[], the relevant part of the
original plan is as follows
87:LogicalRepeatUnion(all=[true])
78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1 }]])
85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)])
81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
condition=[<($0, 100)])
2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]], table=[[T]])
...
(part of the debug error output was cut out)
{noformat}
was:
*Description:*
Need to support recursive queries.
The query
{code:java}
WITH RECURSIVE t(n) AS (SELECT 1 UNION ALL SELECT n + 1 FROM t WHERE n < 100)
SELECT sum(n) FROM t; {code}
should return
{code:java}
5050 {code}
currently returns error
{noformat}
org.apache.ignite.sql.SqlException: IGN-CMN-65535
TraceId:c2961dbf-64fd-4806-a2d9-20368f8454e5 There are not enough rules to
produce a node with desired properties: convention=IGNITE, distr=single,
sort=[].
Missing conversions are LogicalRepeatUnion[convention: NONE -> IGNITE, distr:
any -> single], LogicalRepeatUnion[convention: NONE -> IGNITE, distr: any ->
random]
There are 2 empty subsets:
Empty subset 0: rel#92:RelSubset#6.IGNITE.single.[], the relevant part of the
original plan is as follows
87:LogicalRepeatUnion(all=[true])
78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1 }]])
85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)])
81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
condition=[<($0, 100)])
2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]], table=[[T]])
Empty subset 1: rel#102:RelSubset#6.IGNITE.random.[], the relevant part of the
original plan is as follows
87:LogicalRepeatUnion(all=[true])
78:LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
1:LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1 }]])
85:LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]],
readType=[LAZY], writeType=[LAZY], table=[[T]])
83:LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[]], EXPR$0=[+($0,
1)])
81:LogicalFilter(subset=[rel#82:RelSubset#3.NONE.any.[]],
condition=[<($0, 100)])
2:LogicalTableScan(subset=[rel#80:RelSubset#2.NONE.any.[]], table=[[T]])
Root: rel#91:RelSubset#7.IGNITE.single.[]
Original rel:
LogicalAggregate(subset=[rel#91:RelSubset#7.IGNITE.single.[]], group=[{}],
EXPR$0=[SUM($0)]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
network=Infinity], id = 89
LogicalRepeatUnion(subset=[rel#88:RelSubset#6.NONE.any.[]], all=[true]):
rowcount = 501.0, cumulative cost = IgniteCost [rowCount=Infinity,
cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 87
LogicalTableSpool(subset=[rel#79:RelSubset#1.NONE.any.[0]],
readType=[LAZY], writeType=[LAZY], table=[[T]]): rowcount = 1.0, cumulative
cost = IgniteCost [rowCount=Infinity, cpu=Infinity, memory=Infinity,
io=Infinity, network=Infinity], id = 78
LogicalValues(subset=[rel#77:RelSubset#0.NONE.any.[0]], tuples=[[{ 1
}]]): rowcount = 1.0, cumulative cost = IgniteCost [rowCount=Infinity,
cpu=Infinity, memory=Infinity, io=Infinity, network=Infinity], id = 1
LogicalTableSpool(subset=[rel#86:RelSubset#5.NONE.any.[]], readType=[LAZY],
writeType=[LAZY], table=[[T]]): rowcount = 50.0, cumulative cost = IgniteCost
[rowCount=Infinity, cpu=Infinity, memory=Infinity, io=Infinity,
network=Infinity], id = 85
LogicalProject(subset=[rel#84:RelSubset#4.NONE.any.[
[jira] [Updated] (IGNITE-22932) Sql. Confusing error message when casting numeric literal larger than BIGINT
[
https://issues.apache.org/jira/browse/IGNITE-22932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-22932:
--
Description:
The following test
{code:java}
BigDecimal val = new BigDecimal(Long.MAX_VALUE).add(BigDecimal.ONE);
String query = format( "SELECT {}::TINYINT", val);
checkSqlError(Sql.RUNTIME_ERR, "TINYINT out of range", igniteSql(), query);
{code}
Fails with the following
{noformat}
Expected to include: "TINYINT out of range" actual: "BIGINT out of range"
{noformat}
If the value fits into BIGINT, this test passes.
p.s. fix TODO in codebase.
was:
The following test
{code:java}
BigDecimal val = new BigDecimal(Long.MAX_VALUE).add(BigDecimal.ONE);
String query = format( "SELECT {}::TINYINT", val);
checkSqlError(Sql.RUNTIME_ERR, "TINYINT out of range", igniteSql(), query);
{code}
Fails with the following
{noformat}
Expected to include: "TINYINT out of range" actual: "BIGINT out of range"
{noformat}
If the value fits into BIGINT, this test passes.
p.s. fix TODO in codebase.
> Sql. Confusing error message when casting numeric literal larger than BIGINT
>
>
> Key: IGNITE-22932
> URL: https://issues.apache.org/jira/browse/IGNITE-22932
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> The following test
> {code:java}
> BigDecimal val = new BigDecimal(Long.MAX_VALUE).add(BigDecimal.ONE);
> String query = format( "SELECT {}::TINYINT", val);
> checkSqlError(Sql.RUNTIME_ERR, "TINYINT out of range", igniteSql(), query);
> {code}
> Fails with the following
> {noformat}
> Expected to include: "TINYINT out of range" actual: "BIGINT out of range"
> {noformat}
> If the value fits into BIGINT, this test passes.
> p.s. fix TODO in codebase.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
