[jira] [Updated] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Summary: Sql. Fix behaviour of ROUND function. (was: Sql. Handle return
type of ROUND. )
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for `ROUND(N)`/`ROUND(N, s)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Labels: ignite-3 (was: )
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for `ROUND(N)`/`ROUND(N, s)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for `ROUND(x)`/`ROUND(x, n)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for `ROUND(N)`/`ROUND(N, s)` is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for `ROUND(x)`/`ROUND(x, n)` is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
was:
The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for `ROUND(x)`/`ROUND(x, n)` is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Handle return type of ROUND.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Fix Version/s: 3.0.0-beta2
> Sql. Handle return type of ROUND.
> --
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
> causes issues when reading data from a `BinaryRow` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
> and the return type is then used to construct `RowSchema` (that `RowSchema`
> is then for reading data a `BinaryRow`).
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2
> # RowSchema has NativeType (precision=2, scale=1).
> # And because of that read operation returns 2.0
> # returns 2.0
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20181) KV/Binary view public API should only throw public exceptions for the end user.
[ https://issues.apache.org/jira/browse/IGNITE-20181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20181: - Assignee: Maksim Zhuravkov > KV/Binary view public API should only throw public exceptions for the end > user. > --- > > Key: IGNITE-20181 > URL: https://issues.apache.org/jira/browse/IGNITE-20181 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Revise the error handling of the KV/Binary view public API so that only a > public exception is thrown to the end user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20311) Sql. Handle return type of ROUND.
Maksim Zhuravkov created IGNITE-20311:
-
Summary: Sql. Handle return type of ROUND.
Key: IGNITE-20311
URL: https://issues.apache.org/jira/browse/IGNITE-20311
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
The return type for ROUND(x)/ROUND(x, n) is equal to the type of x, which
causes issues when reading data from a `BinaryRow` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1),
and the return type is then used to construct `RowSchema` (that `RowSchema` is
then for reading data a `BinaryRow`).
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2
# RowSchema has NativeType (precision=2, scale=1).
# And because of that read operation returns 2.0
# returns 2.0
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18670) Sql. It is possible to reference aliases in GROUP BY clause.
[
https://issues.apache.org/jira/browse/IGNITE-18670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762064#comment-17762064
]
Maksim Zhuravkov commented on IGNITE-18670:
---
[~zstan] [~jooger] Could you please review this PR?
> Sql. It is possible to reference aliases in GROUP BY clause.
>
>
> Key: IGNITE-18670
> URL: https://issues.apache.org/jira/browse/IGNITE-18670
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently we expect the query bellow to fail
> {code:java}
> SELECT 1 AS k, SUM(i) FROM integers GROUP BY k+1 ORDER BY 2;
> {code}
> But in https://issues.apache.org/jira/browse/IGNITE-18212 we decided that
> ignite's dialect of the SQL supports this behaviour.
> Update test_group_by.test and mark the query as OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20017) Introduce new command to catalog to create system view
[ https://issues.apache.org/jira/browse/IGNITE-20017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761695#comment-17761695 ] Maksim Zhuravkov commented on IGNITE-20017: --- [~amashenkov], [~korlov] Could you please review this PR? > Introduce new command to catalog to create system view > -- > > Key: IGNITE-20017 > URL: https://issues.apache.org/jira/browse/IGNITE-20017 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > To ensure cluster-wide visibility of the view and seamless integration with > sql engine, all system views must be registered to the catalog. > Let's extend catalog with new set of params|descriptor to support system view > integration. > Should be added > org.apache.ignite.internal.catalog.CatalogManagerImpl#createView -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20226) Sql. Some tests are muted after casting char -> varbinary is disallowed
[
https://issues.apache.org/jira/browse/IGNITE-20226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20226:
--
Description:
Some tests was muted under this issue, some refactoring is helpful.
Because BINARY/VARBINARY is not convertible from any other types, the following
test cases should be disabled or moved to appropriate subclasses
{code}
testCoalesceMissingTypesIsIllegal
testEqConditionWithDynamicParameters
testInsertFromDynamicParameterFromConvertible
testDisallowMismatchTypesOnInsertDynamicParam
testDisallowMismatchTypesOnInsert
testUpdateFromDynamicParameterFromConvertible
{code}
`testCastFromString` can simply be moved to `ItUuidExpressionTest`.
was:
Some tests was muted under this issue, some refactoring is helpful.
Because BINARY/VARBINARY is not convertible from any other types, the following
test cases should be disabled for in appropriate subclasses
{code}
testCoalesceMissingTypesIsIllegal
testEqConditionWithDynamicParameters
testInsertFromDynamicParameterFromConvertible
testDisallowMismatchTypesOnInsertDynamicParam
testDisallowMismatchTypesOnInsert
testUpdateFromDynamicParameterFromConvertible
{code}
`testCastFromString` can simply be moved to `ItUuidExpressionTest`.
> Sql. Some tests are muted after casting char -> varbinary is disallowed
> ---
>
> Key: IGNITE-20226
> URL: https://issues.apache.org/jira/browse/IGNITE-20226
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Some tests was muted under this issue, some refactoring is helpful.
> Because BINARY/VARBINARY is not convertible from any other types, the
> following test cases should be disabled or moved to appropriate subclasses
> {code}
> testCoalesceMissingTypesIsIllegal
> testEqConditionWithDynamicParameters
> testInsertFromDynamicParameterFromConvertible
> testDisallowMismatchTypesOnInsertDynamicParam
> testDisallowMismatchTypesOnInsert
> testUpdateFromDynamicParameterFromConvertible
> {code}
> `testCastFromString` can simply be moved to `ItUuidExpressionTest`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20226) Sql. Some tests are muted after casting char -> varbinary is disallowed
[
https://issues.apache.org/jira/browse/IGNITE-20226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20226:
--
Description:
Some tests was muted under this issue, some refactoring is helpful.
Because BINARY/VARBINARY is not convertible from any other types, the following
test cases should be disabled for in appropriate subclasses
{code}
testCoalesceMissingTypesIsIllegal
testEqConditionWithDynamicParameters
testInsertFromDynamicParameterFromConvertible
testDisallowMismatchTypesOnInsertDynamicParam
testDisallowMismatchTypesOnInsert
testUpdateFromDynamicParameterFromConvertible
{code}
`testCastFromString` can simply be moved to `ItUuidExpressionTest`.
was:Some tests was muted under this issue, some refactoring is helpful
> Sql. Some tests are muted after casting char -> varbinary is disallowed
> ---
>
> Key: IGNITE-20226
> URL: https://issues.apache.org/jira/browse/IGNITE-20226
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> Some tests was muted under this issue, some refactoring is helpful.
> Because BINARY/VARBINARY is not convertible from any other types, the
> following test cases should be disabled for in appropriate subclasses
> {code}
> testCoalesceMissingTypesIsIllegal
> testEqConditionWithDynamicParameters
> testInsertFromDynamicParameterFromConvertible
> testDisallowMismatchTypesOnInsertDynamicParam
> testDisallowMismatchTypesOnInsert
> testUpdateFromDynamicParameterFromConvertible
> {code}
> `testCastFromString` can simply be moved to `ItUuidExpressionTest`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1. Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1.000
# 1.100
# 1.120
# 1.123
# 1.1230
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
> Implementation we agreed upon:
> - For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
> - For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision
> of N's type, and derived_s is scale of N's type.
> Examples:
> {code}
> # ROUND(N):
> SELECT ROUND(1.1)
> # Returns 1. Type: DECIMAL(p, 0)
> # ROUND(N, s):
> SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
> # Returns
> # 1.000
> # 1.100
> # 1.120
> # 1.123
> # 1.1230
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18670) Sql. It is possible to reference aliases in GROUP BY clause.
[
https://issues.apache.org/jira/browse/IGNITE-18670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-18670:
-
Assignee: Maksim Zhuravkov
> Sql. It is possible to reference aliases in GROUP BY clause.
>
>
> Key: IGNITE-18670
> URL: https://issues.apache.org/jira/browse/IGNITE-18670
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently we expect the query bellow to fail
> {code:java}
> SELECT 1 AS k, SUM(i) FROM integers GROUP BY k+1 ORDER BY 2;
> {code}
> But in https://issues.apache.org/jira/browse/IGNITE-18212 we decided that
> ignite's dialect of the SQL supports this behaviour.
> Update test_group_by.test and mark the query as OK.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20239: - Assignee: Maksim Zhuravkov > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictive`. This should not be necessary because types > of rows returned by inputs to set operation should be coerced at the > validation stage by `SqlValidator`/ SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictive` from `SetOpConverterRule` for > both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
Maksim Zhuravkov created IGNITE-20372: - Summary: Sql. EXPLAIN PLAN ignores detail attributes. Key: IGNITE-20372 URL: https://issues.apache.org/jira/browse/IGNITE-20372 Project: Ignite Issue Type: Bug Components: sql Reporter: Maksim Zhuravkov EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of a plan such as detail level, depth, and format. Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL ATTRIBUTES. Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION Format: AS XML, AS JSON, AS DOT. All these properties of SqlExplainNode are ignored, when EXPLAIN PLAN FOR [stmt] is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Fix Version/s: 3.0.0-beta2 > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Fix Version/s: (was: 3.0.0-beta2) > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Fix Version/s: 3.0.0-beta2 > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Labels: ignite-3 (was: ) > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplainNode are ignored, when EXPLAIN PLAN FOR > [stmt] is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20372) Sql. EXPLAIN PLAN ignores detail attributes.
[ https://issues.apache.org/jira/browse/IGNITE-20372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20372: -- Description: EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of a plan such as detail level, depth, and format. Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL ATTRIBUTES. Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION Format: AS XML, AS JSON, AS DOT. All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] is executed. was: EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of a plan such as detail level, depth, and format. Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL ATTRIBUTES. Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION Format: AS XML, AS JSON, AS DOT. All these properties of SqlExplainNode are ignored, when EXPLAIN PLAN FOR [stmt] is executed. > Sql. EXPLAIN PLAN ignores detail attributes. > > > Key: IGNITE-20372 > URL: https://issues.apache.org/jira/browse/IGNITE-20372 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > EXPLAIN PLAN FOR [stmt] in calcite allows to specify additional properties of > a plan such as detail level, depth, and format. > Detail level: EXCLUDING ATTRIBUTES, INCLUDING ATTRIBUTES, INCLUDING ALL > ATTRIBUTES. > Depth: WITH TYPE, WITHOUT IMPLEMENTATION, WITH IMPLEMENTATION > Format: AS XML, AS JSON, AS DOT. > All these properties of SqlExplain are ignored, when EXPLAIN PLAN FOR [stmt] > is executed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20336) Sql. Remove conversion from java types to TypeSpec.
Maksim Zhuravkov created IGNITE-20336: - Summary: Sql. Remove conversion from java types to TypeSpec. Key: IGNITE-20336 URL: https://issues.apache.org/jira/browse/IGNITE-20336 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 JavaType's are no longer used by execution engine, but they remain in execution node tests and TypeUtils::convertToTypeSpec. - Update unit not to use TypeUtils::createRowType(TypeFactory, Class... fields). - Remove conversion from JavaType from TypeUtils::convertToTypeSpec. - Remove TypeUtils::createRowType(TypeFactory, Class... fields) as it is no longer needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20336) Sql. Remove conversion from java types to TypeSpec.
[ https://issues.apache.org/jira/browse/IGNITE-20336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20336: -- Description: JavaTypes are no longer used by execution engine, but they remain in execution node tests and TypeUtils::convertToTypeSpec. - Update unit not to use TypeUtils::createRowType(TypeFactory, Class... fields). - Remove conversion from JavaType from TypeUtils::convertToTypeSpec. - Remove TypeUtils::createRowType(TypeFactory, Class... fields) as it is no longer needed. was: JavaType's are no longer used by execution engine, but they remain in execution node tests and TypeUtils::convertToTypeSpec. - Update unit not to use TypeUtils::createRowType(TypeFactory, Class... fields). - Remove conversion from JavaType from TypeUtils::convertToTypeSpec. - Remove TypeUtils::createRowType(TypeFactory, Class... fields) as it is no longer needed. > Sql. Remove conversion from java types to TypeSpec. > --- > > Key: IGNITE-20336 > URL: https://issues.apache.org/jira/browse/IGNITE-20336 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > JavaTypes are no longer used by execution engine, but they remain in > execution node tests and TypeUtils::convertToTypeSpec. > - Update unit not to use TypeUtils::createRowType(TypeFactory, Class... > fields). > - Remove conversion from JavaType from TypeUtils::convertToTypeSpec. > - Remove TypeUtils::createRowType(TypeFactory, Class... fields) as it is > no longer needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20321) Fix compilation error in ErrorGroups.
Maksim Zhuravkov created IGNITE-20321: - Summary: Fix compilation error in ErrorGroups. Key: IGNITE-20321 URL: https://issues.apache.org/jira/browse/IGNITE-20321 Project: Ignite Issue Type: Task Components: sql Reporter: Maksim Zhuravkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20020) Sql. Support system views in planner
[ https://issues.apache.org/jira/browse/IGNITE-20020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20020: - Assignee: Maksim Zhuravkov > Sql. Support system views in planner > > > Key: IGNITE-20020 > URL: https://issues.apache.org/jira/browse/IGNITE-20020 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > First part of integration system views with sql engine is a support them in > planner. > A few things to keep in mind: > * system views are not updatable -- attempt to execute DML over system view > must result in validation error. > * cluster views and node views have different distribution function -- every > type of view must be covered with decent set of tests, including tests on > colocation-related algorithms -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20181) KV/Binary view public API should only throw public exceptions for the end user.
[ https://issues.apache.org/jira/browse/IGNITE-20181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761831#comment-17761831 ] Maksim Zhuravkov commented on IGNITE-20181: --- [~jooger] [~xtern] Could you please review this PR? > KV/Binary view public API should only throw public exceptions for the end > user. > --- > > Key: IGNITE-20181 > URL: https://issues.apache.org/jira/browse/IGNITE-20181 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Revise the error handling of the KV/Binary view public API so that only a > public exception is thrown to the end user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762417#comment-17762417 ] Maksim Zhuravkov commented on IGNITE-20239: --- [~korlov], [~xtern]. Could you please review this PR? > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictive`. This should not be necessary because types > of rows returned by inputs to set operation should be coerced at the > validation stage by `SqlValidator`/ SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictive` from `SetOpConverterRule` for > both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20350) Investigate of support memory quotas in SQL
[ https://issues.apache.org/jira/browse/IGNITE-20350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20350: - Assignee: Maksim Zhuravkov > Investigate of support memory quotas in SQL > --- > > Key: IGNITE-20350 > URL: https://issues.apache.org/jira/browse/IGNITE-20350 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Right now we don't control of memmory consumption b SQL engine and can't > prevent java OOM during execute SQL. Let's investigate which ways could be > used to calculate using memory and have ability to spill into disk in case > SQL consume too much memory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20311:
-
Assignee: Maksim Zhuravkov
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
> Implementation we agreed upon:
> - For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
> - For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision
> of N's type, and derived_s is scale of N's type.
> Examples:
> {code}
> # ROUND(N):
> SELECT ROUND(1.1)
> # Returns 1. Type: DECIMAL(p, 0)
> # ROUND(N, s):
> SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
> # Returns
> # 1
> # 1.1
> # 1.12
> # 1.123
> # 1.1230
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20311) Sql. Fix behaviour of ROUND function.
[
https://issues.apache.org/jira/browse/IGNITE-20311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20311:
--
Description:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1, Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1
# 1.1
# 1.12
# 1.123
# 1.1230
{code}
was:
The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
causes issues when reading data from a `BinaryTuple` because this way
ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
{code}
SELECT ROUND(1.7)
# Although the implementation of the round function produces 2, RowSchema has
NativeType (precision=2, scale=1).
# Because of that this query returns 2.0
{code}
Implementation we agreed upon:
- For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
- For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision of
N's type, and derived_s is scale of N's type.
Examples:
{code}
# ROUND(N):
SELECT ROUND(1.1)
# Returns 1. Type: DECIMAL(p, 0)
# ROUND(N, s):
SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
# Returns
# 1
# 1.1
# 1.12
# 1.123
# 1.1230
{code}
> Sql. Fix behaviour of ROUND function.
> -
>
> Key: IGNITE-20311
> URL: https://issues.apache.org/jira/browse/IGNITE-20311
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The return type for ROUND(N)/ROUND(N, s) is equal to the type of `N`, which
> causes issues when reading data from a `BinaryTuple` because this way
> ROUND(DECIMAL(2,1)) has return type DECIMAL(2,1):
> {code}
> SELECT ROUND(1.7)
> # Although the implementation of the round function produces 2, RowSchema
> has NativeType (precision=2, scale=1).
> # Because of that this query returns 2.0
> {code}
> Implementation we agreed upon:
> - For `ROUND(N)` return DECIMAL(p, 0) where p is precision of N's type.
> - For `ROUND(N, s)` return DECIMAL(p, derived_s) where where p is precision
> of N's type, and derived_s is scale of N's type.
> Examples:
> {code}
> # ROUND(N):
> SELECT ROUND(1.1)
> # Returns 1, Type: DECIMAL(p, 0)
> # ROUND(N, s):
> SELECT ROUND(1.123, s) FROM (VALUES (0), (1), (2), (3), (4) ) t(s)
> # Returns
> # 1
> # 1.1
> # 1.12
> # 1.123
> # 1.1230
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20574: - Assignee: Maksim Zhuravkov > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[
https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20600:
-
Assignee: Maksim Zhuravkov
> Sql. Updating primary key column produces an incorrect error message.
> -
>
> Key: IGNITE-20600
> URL: https://issues.apache.org/jira/browse/IGNITE-20600
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Primary key column update produces an error that contains incorrect error
> description:
> {code:java}
> sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
> sql("UPDATE my SET id = 1");
> // Err: Cannot update field "ID". You cannot update key, key fields or val
> field in case the val is a complex type
> {code}
> Update error message so it indicates that primary key columns are not
> modifiable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20651) Table API. It is not possible to create a single column RecordView
[
https://issues.apache.org/jira/browse/IGNITE-20651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20651:
--
Summary: Table API. It is not possible to create a single column RecordView
(was: Table API. It is not possible to create a single column RecordView,
AssertionError.)
> Table API. It is not possible to create a single column RecordView
> --
>
> Key: IGNITE-20651
> URL: https://issues.apache.org/jira/browse/IGNITE-20651
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is not possible to create a single column RecordView:
> {code:java}
> @Test
> public void singleColumnMapper() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteTables tables = ignite.tables();
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val VARCHAR)");
> sql("INSERT INTO vals VALUES(1, '1')");
> RecordView idView =
> tables.table("vals").recordView(Mapper.of(Integer.class, "id"));
> assertNotNull(idView.get(null, 1));
> }
> {code}
> Error:
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:ae23631e-28ab-4ef5-ae5d-d61a2417ae97
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:88)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:125)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:123)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:106)
> at
> org.apache.ignite.internal.table.RecordViewImpl.getAsync(RecordViewImpl.java:80)
> at
> org.apache.ignite.internal.table.RecordViewImpl.get(RecordViewImpl.java:72)
>
> aused by: java.lang.AssertionError
> at
> org.apache.ignite.internal.schema.marshaller.reflection.RecordMarshallerImpl.(RecordMarshallerImpl.java:63)
> at
> org.apache.ignite.internal.table.RecordViewImpl.lambda$new$0(RecordViewImpl.java:66)
> at
> org.apache.ignite.internal.table.RecordViewImpl.marshaller(RecordViewImpl.java:354)
> at
> org.apache.ignite.internal.table.RecordViewImpl.marshalKey(RecordViewImpl.java:411)
> at
> org.apache.ignite.internal.table.RecordViewImpl.lambda$getAsync$2(RecordViewImpl.java:81)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:104)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20651) Table API. It is not possible to create a single column RecordView, AssertionError.
Maksim Zhuravkov created IGNITE-20651:
-
Summary: Table API. It is not possible to create a single column
RecordView, AssertionError.
Key: IGNITE-20651
URL: https://issues.apache.org/jira/browse/IGNITE-20651
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Maksim Zhuravkov
It is not possible to create a single column RecordView:
{code:java}
@Test
public void singleColumnMapper() {
Ignite ignite = CLUSTER_NODES.get(0);
IgniteTables tables = ignite.tables();
sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val VARCHAR)");
sql("INSERT INTO vals VALUES(1, '1')");
RecordView idView =
tables.table("vals").recordView(Mapper.of(Integer.class, "id"));
assertNotNull(idView.get(null, 1));
}
{code}
Error:
{code:java}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:ae23631e-28ab-4ef5-ae5d-d61a2417ae97
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:88)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:125)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:123)
at
org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:106)
at
org.apache.ignite.internal.table.RecordViewImpl.getAsync(RecordViewImpl.java:80)
at
org.apache.ignite.internal.table.RecordViewImpl.get(RecordViewImpl.java:72)
aused by: java.lang.AssertionError
at
org.apache.ignite.internal.schema.marshaller.reflection.RecordMarshallerImpl.(RecordMarshallerImpl.java:63)
at
org.apache.ignite.internal.table.RecordViewImpl.lambda$new$0(RecordViewImpl.java:66)
at
org.apache.ignite.internal.table.RecordViewImpl.marshaller(RecordViewImpl.java:354)
at
org.apache.ignite.internal.table.RecordViewImpl.marshalKey(RecordViewImpl.java:411)
at
org.apache.ignite.internal.table.RecordViewImpl.lambda$getAsync$2(RecordViewImpl.java:81)
at
java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
at
java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
at
org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:104)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20444) Sql. Add restrictions for execution tx related statements with single statement mode.
[
https://issues.apache.org/jira/browse/IGNITE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774839#comment-17774839
]
Maksim Zhuravkov commented on IGNITE-20444:
---
[~zstan], [~xtern] Could you please review my PR?
> Sql. Add restrictions for execution tx related statements with single
> statement mode.
> -
>
> Key: IGNITE-20444
> URL: https://issues.apache.org/jira/browse/IGNITE-20444
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Append single statement restrictions for using with new tx related sql syntax
> [1] implementation.
> {code:java}
> try (Session ses = client.sql().createSession()) {
> ses.execute(
> null, "_new transactional statement from
> ignite-20442_" <-- such calls need to be rejected
> ).close();
> ses.execute(
> null,
> "some other sql statement"
> ).close();
> }
> {code}
> [1] https://issues.apache.org/jira/browse/IGNITE-20442
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20444) Sql. Add restrictions for execution tx related statements with single statement mode.
[
https://issues.apache.org/jira/browse/IGNITE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20444:
--
Fix Version/s: 3.0.0-beta2
> Sql. Add restrictions for execution tx related statements with single
> statement mode.
> -
>
> Key: IGNITE-20444
> URL: https://issues.apache.org/jira/browse/IGNITE-20444
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Append single statement restrictions for using with new tx related sql syntax
> [1] implementation.
> {code:java}
> try (Session ses = client.sql().createSession()) {
> ses.execute(
> null, "_new transactional statement from
> ignite-20442_" <-- such calls need to be rejected
> ).close();
> ses.execute(
> null,
> "some other sql statement"
> ).close();
> }
> {code}
> [1] https://issues.apache.org/jira/browse/IGNITE-20442
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20651) Table API. It is not possible to create a single column RecordView
[
https://issues.apache.org/jira/browse/IGNITE-20651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20651:
--
Affects Version/s: (was: 3.0.0-beta1)
> Table API. It is not possible to create a single column RecordView
> --
>
> Key: IGNITE-20651
> URL: https://issues.apache.org/jira/browse/IGNITE-20651
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is not possible to create a single column RecordView:
> {code:java}
> @Test
> public void singleColumnMapper() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteTables tables = ignite.tables();
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val VARCHAR)");
> sql("INSERT INTO vals VALUES(1, '1')");
> RecordView idView =
> tables.table("vals").recordView(Mapper.of(Integer.class, "id"));
> assertNotNull(idView.get(null, 1));
> }
> {code}
> Error:
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:ae23631e-28ab-4ef5-ae5d-d61a2417ae97
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:88)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:125)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:123)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:106)
> at
> org.apache.ignite.internal.table.RecordViewImpl.getAsync(RecordViewImpl.java:80)
> at
> org.apache.ignite.internal.table.RecordViewImpl.get(RecordViewImpl.java:72)
>
> aused by: java.lang.AssertionError
> at
> org.apache.ignite.internal.schema.marshaller.reflection.RecordMarshallerImpl.(RecordMarshallerImpl.java:63)
> at
> org.apache.ignite.internal.table.RecordViewImpl.lambda$new$0(RecordViewImpl.java:66)
> at
> org.apache.ignite.internal.table.RecordViewImpl.marshaller(RecordViewImpl.java:354)
> at
> org.apache.ignite.internal.table.RecordViewImpl.marshalKey(RecordViewImpl.java:411)
> at
> org.apache.ignite.internal.table.RecordViewImpl.lambda$getAsync$2(RecordViewImpl.java:81)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:104)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20651) Table API. It is not possible to create a single column RecordView
[
https://issues.apache.org/jira/browse/IGNITE-20651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20651:
--
Fix Version/s: 3.0.0-beta2
> Table API. It is not possible to create a single column RecordView
> --
>
> Key: IGNITE-20651
> URL: https://issues.apache.org/jira/browse/IGNITE-20651
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> It is not possible to create a single column RecordView:
> {code:java}
> @Test
> public void singleColumnMapper() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteTables tables = ignite.tables();
> sql("CREATE TABLE vals (id INTEGER PRIMARY KEY, val VARCHAR)");
> sql("INSERT INTO vals VALUES(1, '1')");
> RecordView idView =
> tables.table("vals").recordView(Mapper.of(Integer.class, "id"));
> assertNotNull(idView.get(null, 1));
> }
> {code}
> Error:
> {code:java}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:ae23631e-28ab-4ef5-ae5d-d61a2417ae97
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:88)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:125)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:123)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:106)
> at
> org.apache.ignite.internal.table.RecordViewImpl.getAsync(RecordViewImpl.java:80)
> at
> org.apache.ignite.internal.table.RecordViewImpl.get(RecordViewImpl.java:72)
>
> aused by: java.lang.AssertionError
> at
> org.apache.ignite.internal.schema.marshaller.reflection.RecordMarshallerImpl.(RecordMarshallerImpl.java:63)
> at
> org.apache.ignite.internal.table.RecordViewImpl.lambda$new$0(RecordViewImpl.java:66)
> at
> org.apache.ignite.internal.table.RecordViewImpl.marshaller(RecordViewImpl.java:354)
> at
> org.apache.ignite.internal.table.RecordViewImpl.marshalKey(RecordViewImpl.java:411)
> at
> org.apache.ignite.internal.table.RecordViewImpl.lambda$getAsync$2(RecordViewImpl.java:81)
> at
> java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at
> java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:104)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20650) Table API. Field names are not resolved correctly.
Maksim Zhuravkov created IGNITE-20650:
-
Summary: Table API. Field names are not resolved correctly.
Key: IGNITE-20650
URL: https://issues.apache.org/jira/browse/IGNITE-20650
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
Current implementation of Tuple/Record field name is not consistent with
requirements specified in https://issues.apache.org/jira/browse/IGNITE-16322:
Field access:
{code:java}
Ignite ignite = CLUSTER_NODES.get(0);
IgniteTables tables = ignite.tables();
sql("CREATE TABLE \"values\" (\"Id\" INTEGER PRIMARY KEY, \"Val\" VARCHAR)");
sql("INSERT INTO \"values\" VALUES(1, '1')");
Table table = tables.table("\"values\"");
RecordView recordView = table.recordView();
Tuple key = Tuple.create(Map.of("id", 1));
Tuple record = recordView.get(null, key);
// Works
assertNotNull(record);
// Works
assertNotNull(record.value("\"Id\""));
// https://issues.apache.org/jira/browse/IGNITE-16322
// According to the ticket, the following assertions should not fail:
// Invalid column name: columnName=Id
assertNotNull(record.value("Id"));
// Invalid column name: columnName=ID
assertNotNull(record.value("ID"));
{code}
New tuple:
{code:java}
Ignite ignite = CLUSTER_NODES.get(0);
IgniteTables tables = ignite.tables();
sql("CREATE TABLE vals (\"Id\" INTEGER PRIMARY KEY, val VARCHAR)");
sql("INSERT INTO vals VALUES(1, '1')");
Table vals = tables.table("vals");
Tuple val1 = Tuple.create(Map.of("id", 2, "val", "1"));
vals.recordView().insert(null, val1);
Tuple val2 = Tuple.create(Map.of("ID", 2, "val", "2"));
vals.recordView().insert(null, val2);
Tuple val3 = Tuple.create(Map.of("\"Id\"", 3, "val", "3"));
// Error Missed key column: Id
vals.recordView().insert(null, val3);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20677) Sql. Improve error reporting in assertThrowsSqlException.
Maksim Zhuravkov created IGNITE-20677: - Summary: Sql. Improve error reporting in assertThrowsSqlException. Key: IGNITE-20677 URL: https://issues.apache.org/jira/browse/IGNITE-20677 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 Update SqlTestUtils::assertThrowsSqlException to report error group + error code instead of numberic code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20677) Sql. Improve error reporting in assertThrowsSqlException.
[
https://issues.apache.org/jira/browse/IGNITE-20677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20677:
--
Description:
Update SqlTestUtils::assertThrowsSqlException to report error group + error
code instead of numeric code.
Before:
{code:java}
org.opentest4j.AssertionFailedError: org.apache.ignite.sql.SqlException:
IGN-SQL-6 TraceId:e97b09ee-c698-4ee6-9cba-93506591bab3 Failed to validate
query. Table with name 'PUBLIC.TEST' already exists ==>
Expected :131073
Actual :262150
{code}
After:
{code:java}
org.opentest4j.AssertionFailedError: Error does not match.
org.apache.ignite.sql.SqlException: IGN-SQL-6
TraceId:223fe552-f874-474b-beb7-7c7e412c4e1e Failed to validate query. Table
with name 'PUBLIC.TEST' already exists ==>
Expected :TBL#1
Actual :SQL#6
{code}
was:
Update SqlTestUtils::assertThrowsSqlException to report error group + error
code instead of numberic code.
> Sql. Improve error reporting in assertThrowsSqlException.
> -
>
> Key: IGNITE-20677
> URL: https://issues.apache.org/jira/browse/IGNITE-20677
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update SqlTestUtils::assertThrowsSqlException to report error group + error
> code instead of numeric code.
> Before:
> {code:java}
> org.opentest4j.AssertionFailedError: org.apache.ignite.sql.SqlException:
> IGN-SQL-6 TraceId:e97b09ee-c698-4ee6-9cba-93506591bab3 Failed to validate
> query. Table with name 'PUBLIC.TEST' already exists ==>
> Expected :131073
> Actual :262150
> {code}
> After:
> {code:java}
> org.opentest4j.AssertionFailedError: Error does not match.
> org.apache.ignite.sql.SqlException: IGN-SQL-6
> TraceId:223fe552-f874-474b-beb7-7c7e412c4e1e Failed to validate query. Table
> with name 'PUBLIC.TEST' already exists ==>
> Expected :TBL#1
> Actual :SQL#6
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20677) Sql. Improve error reporting in assertThrowsSqlException.
[ https://issues.apache.org/jira/browse/IGNITE-20677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20677: - Assignee: Maksim Zhuravkov > Sql. Improve error reporting in assertThrowsSqlException. > - > > Key: IGNITE-20677 > URL: https://issues.apache.org/jira/browse/IGNITE-20677 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Update SqlTestUtils::assertThrowsSqlException to report error group + error > code instead of numberic code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20677) Sql. Improve error reporting in assertThrowsSqlException.
[ https://issues.apache.org/jira/browse/IGNITE-20677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20677: -- Labels: ignite-3 (was: ) > Sql. Improve error reporting in assertThrowsSqlException. > - > > Key: IGNITE-20677 > URL: https://issues.apache.org/jira/browse/IGNITE-20677 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Update SqlTestUtils::assertThrowsSqlException to report error group + error > code instead of numberic code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20634) Sql. Indices with write-only status should not be accessible via sql schemas.
[ https://issues.apache.org/jira/browse/IGNITE-20634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20634: - Assignee: Maksim Zhuravkov > Sql. Indices with write-only status should not be accessible via sql schemas. > > - > > Key: IGNITE-20634 > URL: https://issues.apache.org/jira/browse/IGNITE-20634 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment SqlSchemaManager ignores write-only index status and returns > all indices, which may lead to scan/key-lookups over an index that is not > fully built. > Update SqlSchemaManager to ignore such indices. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20455) Sql. Test Framework. Add System View support.
[ https://issues.apache.org/jira/browse/IGNITE-20455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20455: - Assignee: Maksim Zhuravkov > Sql. Test Framework. Add System View support. > -- > > Key: IGNITE-20455 > URL: https://issues.apache.org/jira/browse/IGNITE-20455 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement test system view builders - standalone one > (TestBuilders::systemView()) and one for test cluster > (ClusterBuilder::addSystemView()). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20356) Sql. Rework RowHandler "set" operation.
[
https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20356:
-
Assignee: Maksim Zhuravkov
> Sql. Rework RowHandler "set" operation.
> ---
>
> Key: IGNITE-20356
> URL: https://issues.apache.org/jira/browse/IGNITE-20356
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
> This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}"
> method
> Instead of using {{set(int, RowT, Object)}} method, we can use the
> {{append(RowT, Object)}} method to add field values sequentially.
> We need:
> * Add a new RowFactory method that will return a builder that allows you to
> append values to row and build the row.
> * Remove the {{RowHandler#set()}} method and rework all related code/tests
> to use the builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20795) Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes.
[ https://issues.apache.org/jira/browse/IGNITE-20795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20795: -- Fix Version/s: 3.0.0-beta2 > Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes. > > > Key: IGNITE-20795 > URL: https://issues.apache.org/jira/browse/IGNITE-20795 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IgniteTableFunctionScan implements SourceAwareIgniteRel but returns hardcoded > sourceId that is equal to -1, because QuerySplitter does not visit nodes of > this type. > Update QuerySpliiter to visit IgniteTableFunctionScan and fix this behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20795) Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes.
Maksim Zhuravkov created IGNITE-20795: - Summary: Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes. Key: IGNITE-20795 URL: https://issues.apache.org/jira/browse/IGNITE-20795 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov IgniteTableFunctionScan implements SourceAwareIgniteRel but returns hardcoded sourceId that is equal to -1, because QuerySplitter does not visit nodes of this type. Update QuerySpliiter to visit IgniteTableFunctionScan and fix this behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20356) Sql. Rework RowHandler "set" operation.
[
https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783213#comment-17783213
]
Maksim Zhuravkov commented on IGNITE-20356:
---
[~xtern] [~amashenkov] could you please review my PR?
> Sql. Rework RowHandler "set" operation.
> ---
>
> Key: IGNITE-20356
> URL: https://issues.apache.org/jira/browse/IGNITE-20356
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
> This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}"
> method
> Instead of using {{set(int, RowT, Object)}} method, we can use the
> {{append(RowT, Object)}} method to add field values sequentially.
> We need:
> * Add a new RowFactory method that will return a builder that allows you to
> append values to row and build the row.
> * Remove the {{RowHandler#set()}} method and rework all related code/tests
> to use the builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20795) Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes.
[ https://issues.apache.org/jira/browse/IGNITE-20795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20795: -- Labels: ignite-3 (was: ) > Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes. > > > Key: IGNITE-20795 > URL: https://issues.apache.org/jira/browse/IGNITE-20795 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > IgniteTableFunctionScan implements SourceAwareIgniteRel but returns hardcoded > sourceId that is equal to -1, because QuerySplitter does not visit nodes of > this type. > Update QuerySpliiter to visit IgniteTableFunctionScan and fix this behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20020) Sql. Support system views in planner
[ https://issues.apache.org/jira/browse/IGNITE-20020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20020: -- Fix Version/s: 3.0.0-beta2 > Sql. Support system views in planner > > > Key: IGNITE-20020 > URL: https://issues.apache.org/jira/browse/IGNITE-20020 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > First part of integration system views with sql engine is a support them in > planner. > A few things to keep in mind: > * system views are not updatable -- attempt to execute DML over system view > must result in validation error. > * cluster views and node views have different distribution function -- every > type of view must be covered with decent set of tests, including tests on > colocation-related algorithms -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20020) Sql. Support system views in planner
[ https://issues.apache.org/jira/browse/IGNITE-20020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17767000#comment-17767000 ] Maksim Zhuravkov commented on IGNITE-20020: --- [~korlov] [~zstan] Could you please review my PR? > Sql. Support system views in planner > > > Key: IGNITE-20020 > URL: https://issues.apache.org/jira/browse/IGNITE-20020 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > First part of integration system views with sql engine is a support them in > planner. > A few things to keep in mind: > * system views are not updatable -- attempt to execute DML over system view > must result in validation error. > * cluster views and node views have different distribution function -- every > type of view must be covered with decent set of tests, including tests on > colocation-related algorithms -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-20437) Sql. Support system views in execution
[ https://issues.apache.org/jira/browse/IGNITE-20437 ] Maksim Zhuravkov deleted comment on IGNITE-20437: --- was (Author: JIRAUSER298618): [~korlov] [~zstan] Could you please review my PR? > Sql. Support system views in execution > -- > > Key: IGNITE-20437 > URL: https://issues.apache.org/jira/browse/IGNITE-20437 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > After both IGNITE-20019 and IGNITE-20020 will be implemented, we can complete > integration of system view to the SQL engine by implementing execution part > of integration. Following parts of the SQL engine must be covered under this > ticket: > * mapping of plans with system views to the actual topology > * initialisation of distributed query tree. That is, translation of a > fragment containing scan over system view to a execution tree > * execution node, that will drain the cursor provided by system view -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20437) Sql. Support system views in execution
[ https://issues.apache.org/jira/browse/IGNITE-20437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17766999#comment-17766999 ] Maksim Zhuravkov commented on IGNITE-20437: --- [~korlov] [~zstan] Could you please review my PR? > Sql. Support system views in execution > -- > > Key: IGNITE-20437 > URL: https://issues.apache.org/jira/browse/IGNITE-20437 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > After both IGNITE-20019 and IGNITE-20020 will be implemented, we can complete > integration of system view to the SQL engine by implementing execution part > of integration. Following parts of the SQL engine must be covered under this > ticket: > * mapping of plans with system views to the actual topology > * initialisation of distributed query tree. That is, translation of a > fragment containing scan over system view to a execution tree > * execution node, that will drain the cursor provided by system view -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20456) Sql. Move insert/update/delete rows methods from TableDescriptor to IgniteTable.
Maksim Zhuravkov created IGNITE-20456: - Summary: Sql. Move insert/update/delete rows methods from TableDescriptor to IgniteTable. Key: IGNITE-20456 URL: https://issues.apache.org/jira/browse/IGNITE-20456 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov TableDescriptor defines methods for accessing table columns (1), data distribution (2), and row type building for DML operations (3). Since methods (1) and (2) are valid for both table and system views, but (3) are only legal for tables, it would be better to move methods (3) to `IgniteTable`. We may also rename `TableDescriptor`, because it is shared for both tables and system views. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20456) Sql. Move insert/update/delete rows methods from TableDescriptor to IgniteTable.
[ https://issues.apache.org/jira/browse/IGNITE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20456: -- Epic Link: IGNITE-20014 > Sql. Move insert/update/delete rows methods from TableDescriptor to > IgniteTable. > > > Key: IGNITE-20456 > URL: https://issues.apache.org/jira/browse/IGNITE-20456 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > TableDescriptor defines methods for accessing table columns (1), data > distribution (2), and row type building for DML operations (3). > Since methods (1) and (2) are valid for both table and system views, but (3) > are only legal for tables, it would be better to move methods (3) to > `IgniteTable`. > We may also rename `TableDescriptor` as part of this issue, because it is > shared for both tables and system views. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20456) Sql. Move insert/update/delete rows methods from TableDescriptor to IgniteTable.
[ https://issues.apache.org/jira/browse/IGNITE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20456: -- Labels: ignite-3 (was: ) > Sql. Move insert/update/delete rows methods from TableDescriptor to > IgniteTable. > > > Key: IGNITE-20456 > URL: https://issues.apache.org/jira/browse/IGNITE-20456 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > TableDescriptor defines methods for accessing table columns (1), data > distribution (2), and row type building for DML operations (3). > Since methods (1) and (2) are valid for both table and system views, but (3) > are only legal for tables, it would be better to move methods (3) to > `IgniteTable`. > We may also rename `TableDescriptor` as part of this issue, because it is > shared for both tables and system views. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20455) Sql. Test Framework. Add System View support.
[ https://issues.apache.org/jira/browse/IGNITE-20455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20455: -- Description: Implement test system view builders - standalone one (TestBuilders::systemView()) and one for test cluster (ClusterBuilder::addSystemView()). was: Implement test system view builders - standalone one (TestBuilders::systemView()) and one for test cluster (CLusterBuilder::addSystemView()). > Sql. Test Framework. Add System View support. > -- > > Key: IGNITE-20455 > URL: https://issues.apache.org/jira/browse/IGNITE-20455 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Implement test system view builders - standalone one > (TestBuilders::systemView()) and one for test cluster > (ClusterBuilder::addSystemView()). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20455) Sql. Test Framework. Add System View support.
[ https://issues.apache.org/jira/browse/IGNITE-20455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20455: -- Epic Link: IGNITE-20014 > Sql. Test Framework. Add System View support. > -- > > Key: IGNITE-20455 > URL: https://issues.apache.org/jira/browse/IGNITE-20455 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Implement test system view builders - standalone one > (TestBuilders::systemView()) and one for test cluster > (ClusterBuilder::addSystemView()). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20456) Sql. Move insert/update/delete rows methods from TableDescriptor to IgniteTable.
[ https://issues.apache.org/jira/browse/IGNITE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20456: -- Fix Version/s: 3.0.0-beta2 > Sql. Move insert/update/delete rows methods from TableDescriptor to > IgniteTable. > > > Key: IGNITE-20456 > URL: https://issues.apache.org/jira/browse/IGNITE-20456 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Fix For: 3.0.0-beta2 > > > TableDescriptor defines methods for accessing table columns (1), data > distribution (2), and row type building for DML operations (3). > Since methods (1) and (2) are valid for both table and system views, but (3) > are only legal for tables, it would be better to move methods (3) to > `IgniteTable`. > We may also rename `TableDescriptor` as part of this issue, because it is > shared for both tables and system views. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20456) Sql. Move insert/update/delete rows methods from TableDescriptor to IgniteTable.
[ https://issues.apache.org/jira/browse/IGNITE-20456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20456: -- Description: TableDescriptor defines methods for accessing table columns (1), data distribution (2), and row type building for DML operations (3). Since methods (1) and (2) are valid for both table and system views, but (3) are only legal for tables, it would be better to move methods (3) to `IgniteTable`. We may also rename `TableDescriptor` as part of this issue, because it is shared for both tables and system views. was: TableDescriptor defines methods for accessing table columns (1), data distribution (2), and row type building for DML operations (3). Since methods (1) and (2) are valid for both table and system views, but (3) are only legal for tables, it would be better to move methods (3) to `IgniteTable`. We may also rename `TableDescriptor`, because it is shared for both tables and system views. > Sql. Move insert/update/delete rows methods from TableDescriptor to > IgniteTable. > > > Key: IGNITE-20456 > URL: https://issues.apache.org/jira/browse/IGNITE-20456 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > > TableDescriptor defines methods for accessing table columns (1), data > distribution (2), and row type building for DML operations (3). > Since methods (1) and (2) are valid for both table and system views, but (3) > are only legal for tables, it would be better to move methods (3) to > `IgniteTable`. > We may also rename `TableDescriptor` as part of this issue, because it is > shared for both tables and system views. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20455) Sql. Test Framework. Add System View support.
[ https://issues.apache.org/jira/browse/IGNITE-20455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20455: -- Labels: ignite-3 (was: ) > Sql. Test Framework. Add System View support. > -- > > Key: IGNITE-20455 > URL: https://issues.apache.org/jira/browse/IGNITE-20455 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Implement test system view builders - standalone one > (TestBuilders::systemView()) and one for test cluster > (CLusterBuilder::addSystemView()). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20455) Sql. Test Framework. Add System View support.
[ https://issues.apache.org/jira/browse/IGNITE-20455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20455: -- Fix Version/s: 3.0.0-beta2 > Sql. Test Framework. Add System View support. > -- > > Key: IGNITE-20455 > URL: https://issues.apache.org/jira/browse/IGNITE-20455 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Fix For: 3.0.0-beta2 > > > Implement test system view builders - standalone one > (TestBuilders::systemView()) and one for test cluster > (CLusterBuilder::addSystemView()). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20461) Sql. Document SourceAwareIgniteRel.
[ https://issues.apache.org/jira/browse/IGNITE-20461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20461: -- Labels: ignite-3 (was: ) > Sql. Document SourceAwareIgniteRel. > --- > > Key: IGNITE-20461 > URL: https://issues.apache.org/jira/browse/IGNITE-20461 > Project: Ignite > Issue Type: Improvement >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Update javadoc to SourceAwareIgniteRel. Docs should answer the folloing > questions: > - Why do we need this interface. > - How source id is used. > - Want does source = -1 means. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20461) Sql. Document SourceAwareIgniteRel.
[ https://issues.apache.org/jira/browse/IGNITE-20461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20461: -- Description: Update javadocs of SourceAwareIgniteRel. Docs should answer the folloing questions: - Why do we need this interface. - How source id property is used. - Want does source = -1 mean. was: Update javadoc to SourceAwareIgniteRel. Docs should answer the folloing questions: - Why do we need this interface. - How source id is used. - Want does source = -1 means. > Sql. Document SourceAwareIgniteRel. > --- > > Key: IGNITE-20461 > URL: https://issues.apache.org/jira/browse/IGNITE-20461 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Update javadocs of SourceAwareIgniteRel. Docs should answer the folloing > questions: > - Why do we need this interface. > - How source id property is used. > - Want does source = -1 mean. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20455) Sql. Test Framework. Add System View support.
Maksim Zhuravkov created IGNITE-20455: - Summary: Sql. Test Framework. Add System View support. Key: IGNITE-20455 URL: https://issues.apache.org/jira/browse/IGNITE-20455 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Implement test system view builders - standalone one (TestBuilders::systemView()) and one for test cluster (CLusterBuilder::addSystemView()). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20461) Sql. Document SourceAwareIgniteRel.
[ https://issues.apache.org/jira/browse/IGNITE-20461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20461: -- Component/s: sql > Sql. Document SourceAwareIgniteRel. > --- > > Key: IGNITE-20461 > URL: https://issues.apache.org/jira/browse/IGNITE-20461 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > Update javadoc to SourceAwareIgniteRel. Docs should answer the folloing > questions: > - Why do we need this interface. > - How source id is used. > - Want does source = -1 means. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20461) Sql. Document SourceAwareIgniteRel.
Maksim Zhuravkov created IGNITE-20461: - Summary: Sql. Document SourceAwareIgniteRel. Key: IGNITE-20461 URL: https://issues.apache.org/jira/browse/IGNITE-20461 Project: Ignite Issue Type: Improvement Reporter: Maksim Zhuravkov Update javadoc to SourceAwareIgniteRel. Docs should answer the folloing questions: - Why do we need this interface. - How source id is used. - Want does source = -1 means. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20461) Sql. Document SourceAwareIgniteRel.
[ https://issues.apache.org/jira/browse/IGNITE-20461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20461: -- Fix Version/s: 3.0.0-beta2 > Sql. Document SourceAwareIgniteRel. > --- > > Key: IGNITE-20461 > URL: https://issues.apache.org/jira/browse/IGNITE-20461 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Update javadoc to SourceAwareIgniteRel. Docs should answer the folloing > questions: > - Why do we need this interface. > - How source id is used. > - Want does source = -1 means. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause resource leak.
Maksim Zhuravkov created IGNITE-20534:
-
Summary: Transactions. It is possible to call enlist on a
rollbacked transaction and cause resource leak.
Key: IGNITE-20534
URL: https://issues.apache.org/jira/browse/IGNITE-20534
Project: Ignite
Issue Type: Improvement
Affects Versions: 3.0.0-beta2
Reporter: Maksim Zhuravkov
It is possible to rollback a transaction, invoke a modification operation, open
another transaction and get 'Failed to acquire a lock due to a conflict' when
accessing that table.
Reproducer:
{code:java}
@Test
public void testLockIsNotReleasedAfterTxRollback() {
Ignite ignite = CLUSTER_NODES.get(0);
IgniteSql sql = ignite.sql();
try (Session ses = ignite.sql().createSession()) {
ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
PRIMARY KEY, val INTEGER)").affectedRows();
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin();
assertThrows(RuntimeException.class, () -> session.execute(tx,
"SELECT 1/0"));
tx.rollback();
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
line is commented out, everything works fine.
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin(new
TransactionOptions().readOnly(false));
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to a
conflict [txId=018af087-fb6b---e9bae05c,
conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
tx.commit();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause resource leak.
[
https://issues.apache.org/jira/browse/IGNITE-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20534:
--
Labels: ignite-3 (was: )
> Transactions. It is possible to call enlist on a rollbacked transaction and
> cause resource leak.
>
>
> Key: IGNITE-20534
> URL: https://issues.apache.org/jira/browse/IGNITE-20534
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is possible to rollback a transaction, invoke a modification operation,
> open another transaction and get 'Failed to acquire a lock due to a conflict'
> when accessing that table.
> Reproducer:
> {code:java}
> @Test
> public void testLockIsNotReleasedAfterTxRollback() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteSql sql = ignite.sql();
> try (Session ses = ignite.sql().createSession()) {
> ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
> PRIMARY KEY, val INTEGER)").affectedRows();
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin();
> assertThrows(RuntimeException.class, () -> session.execute(tx,
> "SELECT 1/0"));
> tx.rollback();
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
> line is commented out, everything works fine.
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin(new
> TransactionOptions().readOnly(false));
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
> TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to
> a conflict [txId=018af087-fb6b---e9bae05c,
> conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
> intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> tx.commit();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause a resource leak.
[
https://issues.apache.org/jira/browse/IGNITE-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20534:
--
Description:
It is possible to rollback a transaction, invoke a modification operation on
some table, open another transaction and get 'Failed to acquire a lock due to a
conflict' when accessing that table.
Reproducer:
{code:java}
@Test
public void testLockIsNotReleasedAfterTxRollback() {
Ignite ignite = CLUSTER_NODES.get(0);
IgniteSql sql = ignite.sql();
try (Session ses = ignite.sql().createSession()) {
ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
PRIMARY KEY, val INTEGER)").affectedRows();
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin();
assertThrows(RuntimeException.class, () -> session.execute(tx,
"SELECT 1/0"));
tx.rollback();
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
line is commented out, everything works fine.
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin(new
TransactionOptions().readOnly(false));
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to a
conflict [txId=018af087-fb6b---e9bae05c,
conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
tx.commit();
}
}
{code}
was:
It is possible to rollback a transaction, invoke a modification operation, open
another transaction and get 'Failed to acquire a lock due to a conflict' when
accessing that table.
Reproducer:
{code:java}
@Test
public void testLockIsNotReleasedAfterTxRollback() {
Ignite ignite = CLUSTER_NODES.get(0);
IgniteSql sql = ignite.sql();
try (Session ses = ignite.sql().createSession()) {
ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
PRIMARY KEY, val INTEGER)").affectedRows();
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin();
assertThrows(RuntimeException.class, () -> session.execute(tx,
"SELECT 1/0"));
tx.rollback();
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
line is commented out, everything works fine.
}
try (Session session = sql.createSession()) {
Transaction tx = ignite.transactions().begin(new
TransactionOptions().readOnly(false));
session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to a
conflict [txId=018af087-fb6b---e9bae05c,
conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
tx.commit();
}
}
{code}
> Transactions. It is possible to call enlist on a rollbacked transaction and
> cause a resource leak.
> --
>
> Key: IGNITE-20534
> URL: https://issues.apache.org/jira/browse/IGNITE-20534
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is possible to rollback a transaction, invoke a modification operation on
> some table, open another transaction and get 'Failed to acquire a lock due to
> a conflict' when accessing that table.
> Reproducer:
> {code:java}
> @Test
> public void testLockIsNotReleasedAfterTxRollback() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteSql sql = ignite.sql();
> try (Session ses = ignite.sql().createSession()) {
> ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
> PRIMARY KEY, val INTEGER)").affectedRows();
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin();
> assertThrows(RuntimeException.class, () -> session.execute(tx,
> "SELECT 1/0"));
> tx.rollback();
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
> line is commented out, everything works fine.
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin(new
> TransactionOptions().readOnly(false));
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
> TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to
[jira] [Updated] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause a resource leak.
[
https://issues.apache.org/jira/browse/IGNITE-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20534:
--
Summary: Transactions. It is possible to call enlist on a rollbacked
transaction and cause a resource leak. (was: Transactions. It is possible to
call enlist on a rollbacked transaction and cause resource leak.)
> Transactions. It is possible to call enlist on a rollbacked transaction and
> cause a resource leak.
> --
>
> Key: IGNITE-20534
> URL: https://issues.apache.org/jira/browse/IGNITE-20534
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is possible to rollback a transaction, invoke a modification operation,
> open another transaction and get 'Failed to acquire a lock due to a conflict'
> when accessing that table.
> Reproducer:
> {code:java}
> @Test
> public void testLockIsNotReleasedAfterTxRollback() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteSql sql = ignite.sql();
> try (Session ses = ignite.sql().createSession()) {
> ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
> PRIMARY KEY, val INTEGER)").affectedRows();
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin();
> assertThrows(RuntimeException.class, () -> session.execute(tx,
> "SELECT 1/0"));
> tx.rollback();
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
> line is commented out, everything works fine.
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin(new
> TransactionOptions().readOnly(false));
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
> TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to
> a conflict [txId=018af087-fb6b---e9bae05c,
> conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
> intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> tx.commit();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20411) IndexOutOfBoundsException in SqlRowHandler$BinaryTupleRowWrapper
[
https://issues.apache.org/jira/browse/IGNITE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769594#comment-17769594
]
Maksim Zhuravkov commented on IGNITE-20411:
---
[~amashenkov], [~zstan] Could you please review this PR?
> IndexOutOfBoundsException in SqlRowHandler$BinaryTupleRowWrapper
>
>
> Key: IGNITE-20411
> URL: https://issues.apache.org/jira/browse/IGNITE-20411
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Exception:*
> {code}
> java.lang.IndexOutOfBoundsException: Index 2 out of bounds for length 2
> at
> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at
> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:459)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler$BinaryTupleRowWrapper.get(SqlRowHandler.java:357)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:74)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:65)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.convertRow(UpdatableTableImpl.java:337)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insertAll(UpdatableTableImpl.java:242)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:219)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:190)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:163)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushUnordered(Inbox.java:344)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.push(Inbox.java:202)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.onBatchReceived(Inbox.java:180)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:167)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$1(ExchangeServiceImpl.java:73)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:150)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:119)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> *Reproducer:*
> Add this test to *ItSqlSynchronousApiTest*
> {code:java}
> @Test
> public void testUpdateTable() {
> IgniteSql sql = igniteSql();
> Session ses = sql.createSession();
> checkDdl(true, ses, "CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0
> INT)");
> var upsertFut = CompletableFuture.runAsync(() -> {
> for (int i = 0; i < 1000; i++) {
> checkDml(1, ses, "INSERT INTO TEST VALUES (?, ?)", i, i);
> }
> });
> checkDdl(true, ses, "ALTER TABLE TEST ADD COLUMN VAL1 INT DEFAULT
> -1");
> upsertFut.join();
> }
> {code}
> *NOTE*
> Original exception stack trace seems to be lost if you just run the test, I
> had to use debugger to get it. Consider addressing this too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20411) IndexOutOfBoundsException in SqlRowHandler$BinaryTupleRowWrapper
[
https://issues.apache.org/jira/browse/IGNITE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17769594#comment-17769594
]
Maksim Zhuravkov edited comment on IGNITE-20411 at 9/27/23 1:08 PM:
[~amashenkov], [~zstan] Could you please review my PR?
was (Author: JIRAUSER298618):
[~amashenkov], [~zstan] Could you please review this PR?
> IndexOutOfBoundsException in SqlRowHandler$BinaryTupleRowWrapper
>
>
> Key: IGNITE-20411
> URL: https://issues.apache.org/jira/browse/IGNITE-20411
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Exception:*
> {code}
> java.lang.IndexOutOfBoundsException: Index 2 out of bounds for length 2
> at
> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at
> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:459)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler$BinaryTupleRowWrapper.get(SqlRowHandler.java:357)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:74)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:65)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.convertRow(UpdatableTableImpl.java:337)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insertAll(UpdatableTableImpl.java:242)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:219)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:190)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:163)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushUnordered(Inbox.java:344)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.push(Inbox.java:202)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.onBatchReceived(Inbox.java:180)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:167)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$1(ExchangeServiceImpl.java:73)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:150)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:119)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> *Reproducer:*
> Add this test to *ItSqlSynchronousApiTest*
> {code:java}
> @Test
> public void testUpdateTable() {
> IgniteSql sql = igniteSql();
> Session ses = sql.createSession();
> checkDdl(true, ses, "CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0
> INT)");
> var upsertFut = CompletableFuture.runAsync(() -> {
> for (int i = 0; i < 1000; i++) {
> checkDml(1, ses, "INSERT INTO TEST VALUES (?, ?)", i, i);
> }
> });
> checkDdl(true, ses, "ALTER TABLE TEST ADD COLUMN VAL1 INT DEFAULT
> -1");
> upsertFut.join();
> }
> {code}
> *NOTE*
> Original exception stack trace seems to be lost if you just run the test, I
> had to use debugger to get it. Consider addressing this too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20411) IndexOutOfBoundsException in SqlRowHandler$BinaryTupleRowWrapper
[
https://issues.apache.org/jira/browse/IGNITE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20411:
-
Assignee: Maksim Zhuravkov
> IndexOutOfBoundsException in SqlRowHandler$BinaryTupleRowWrapper
>
>
> Key: IGNITE-20411
> URL: https://issues.apache.org/jira/browse/IGNITE-20411
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Assignee: Maksim Zhuravkov
>Priority: Critical
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Exception:*
> {code}
> java.lang.IndexOutOfBoundsException: Index 2 out of bounds for length 2
> at
> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at
> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.base/java.util.Objects.checkIndex(Objects.java:372)
> at java.base/java.util.ArrayList.get(ArrayList.java:459)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler$BinaryTupleRowWrapper.get(SqlRowHandler.java:357)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:74)
> at
> org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:65)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.convertRow(UpdatableTableImpl.java:337)
> at
> org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insertAll(UpdatableTableImpl.java:242)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:219)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:190)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:163)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushUnordered(Inbox.java:344)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.push(Inbox.java:202)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.Inbox.onBatchReceived(Inbox.java:180)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:167)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$1(ExchangeServiceImpl.java:73)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:150)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:119)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
> *Reproducer:*
> Add this test to *ItSqlSynchronousApiTest*
> {code:java}
> @Test
> public void testUpdateTable() {
> IgniteSql sql = igniteSql();
> Session ses = sql.createSession();
> checkDdl(true, ses, "CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0
> INT)");
> var upsertFut = CompletableFuture.runAsync(() -> {
> for (int i = 0; i < 1000; i++) {
> checkDml(1, ses, "INSERT INTO TEST VALUES (?, ?)", i, i);
> }
> });
> checkDdl(true, ses, "ALTER TABLE TEST ADD COLUMN VAL1 INT DEFAULT
> -1");
> upsertFut.join();
> }
> {code}
> *NOTE*
> Original exception stack trace seems to be lost if you just run the test, I
> had to use debugger to get it. Consider addressing this too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20411) IndexOutOfBoundsException in SqlRowHandler$BinaryTupleRowWrapper
[
https://issues.apache.org/jira/browse/IGNITE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20411:
--
Description:
*Exception:*
{code}
java.lang.IndexOutOfBoundsException: Index 2 out of bounds for length 2
at
java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at
java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:459)
at
org.apache.ignite.internal.sql.engine.exec.SqlRowHandler$BinaryTupleRowWrapper.get(SqlRowHandler.java:357)
at
org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:74)
at
org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:65)
at
org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.convertRow(UpdatableTableImpl.java:337)
at
org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insertAll(UpdatableTableImpl.java:242)
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:219)
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:190)
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:163)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.pushUnordered(Inbox.java:344)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.push(Inbox.java:202)
at
org.apache.ignite.internal.sql.engine.exec.rel.Inbox.onBatchReceived(Inbox.java:180)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:167)
at
org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$1(ExchangeServiceImpl.java:73)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:150)
at
org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:119)
at
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
{code}
*Reproducer:*
Add this test to *ItSqlSynchronousApiTest*
{code:java}
@Test
public void testUpdateTable() {
IgniteSql sql = igniteSql();
Session ses = sql.createSession();
checkDdl(true, ses, "CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT)");
var upsertFut = CompletableFuture.runAsync(() -> {
for (int i = 0; i < 1000; i++) {
checkDml(1, ses, "INSERT INTO TEST VALUES (?, ?)", i, i);
}
});
checkDdl(true, ses, "ALTER TABLE TEST ADD COLUMN VAL1 INT DEFAULT -1");
upsertFut.join();
}
{code}
*NOTE*
Original exception stack trace seems to be lost if you just run the test, I had
to use debugger to get it. Consider addressing this too.
This use was fixed in IGNITE-20520. This ticket just removed
UpdateSchemaListener that is no longer in use.
was:
*Exception:*
{code}
java.lang.IndexOutOfBoundsException: Index 2 out of bounds for length 2
at
java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at
java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.base/java.util.Objects.checkIndex(Objects.java:372)
at java.base/java.util.ArrayList.get(ArrayList.java:459)
at
org.apache.ignite.internal.sql.engine.exec.SqlRowHandler$BinaryTupleRowWrapper.get(SqlRowHandler.java:357)
at
org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:74)
at
org.apache.ignite.internal.sql.engine.exec.SqlRowHandler.get(SqlRowHandler.java:65)
at
org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.convertRow(UpdatableTableImpl.java:337)
at
org.apache.ignite.internal.sql.engine.exec.UpdatableTableImpl.insertAll(UpdatableTableImpl.java:242)
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:219)
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:190)
at
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:163)
at
[jira] [Assigned] (IGNITE-20442) Sql. Extend grammar with transaction related statements.
[
https://issues.apache.org/jira/browse/IGNITE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20442:
-
Assignee: Maksim Zhuravkov
> Sql. Extend grammar with transaction related statements.
>
>
> Key: IGNITE-20442
> URL: https://issues.apache.org/jira/browse/IGNITE-20442
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> In order to process multistatement queries we need to support the following
> sql grammar to start/finish transactions.
> {code}
> ::=
> START TRANSACTION []
> ::= READ ONLY | READ WRITE
> {code}
> {code}
> ::=
> COMMIT
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20439) Sql. Support multiple schemas in CatalogSqlSchemaManager.
[ https://issues.apache.org/jira/browse/IGNITE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20439: -- Issue Type: Improvement (was: Bug) > Sql. Support multiple schemas in CatalogSqlSchemaManager. > - > > Key: IGNITE-20439 > URL: https://issues.apache.org/jira/browse/IGNITE-20439 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > > CatalogSqlSchemaManager::schema(name) returns a SchemaPlus that only includes > a schema with the specified name, > this makes accessing objects from other schemas not possible. Update > CatalogSqlSchemaManager::schema to include other schemas as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20439) Sql. Support multiple schemas in CatalogSqlSchemaManager.
Maksim Zhuravkov created IGNITE-20439: - Summary: Sql. Support multiple schemas in CatalogSqlSchemaManager. Key: IGNITE-20439 URL: https://issues.apache.org/jira/browse/IGNITE-20439 Project: Ignite Issue Type: Bug Components: sql Reporter: Maksim Zhuravkov CatalogSqlSchemaManager::schema(name) returns a SchemaPlus that only includes a schema with the specified name, this makes accessing objects from other schemas not possible. Update CatalogSqlSchemaManager::schema to include other schemas as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20439) Sql. Support multiple schemas in CatalogSqlSchemaManager.
[ https://issues.apache.org/jira/browse/IGNITE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20439: -- Labels: ignite-3 (was: ) > Sql. Support multiple schemas in CatalogSqlSchemaManager. > - > > Key: IGNITE-20439 > URL: https://issues.apache.org/jira/browse/IGNITE-20439 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > CatalogSqlSchemaManager::schema(name) returns a SchemaPlus that only includes > a schema with the specified name, > this makes accessing objects from other schemas not possible. Update > CatalogSqlSchemaManager::schema to include other schemas as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20439) Sql. Support multiple schemas in CatalogSqlSchemaManager.
[ https://issues.apache.org/jira/browse/IGNITE-20439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20439: -- Fix Version/s: 3.0.0-beta2 > Sql. Support multiple schemas in CatalogSqlSchemaManager. > - > > Key: IGNITE-20439 > URL: https://issues.apache.org/jira/browse/IGNITE-20439 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Fix For: 3.0.0-beta2 > > > CatalogSqlSchemaManager::schema(name) returns a SchemaPlus that only includes > a schema with the specified name, > this makes accessing objects from other schemas not possible. Update > CatalogSqlSchemaManager::schema to include other schemas as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17882) Remove org.apache.ignite.binary.BinaryObject from public API
[ https://issues.apache.org/jira/browse/IGNITE-17882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-17882: - Assignee: Maksim Zhuravkov > Remove org.apache.ignite.binary.BinaryObject from public API > > > Key: IGNITE-17882 > URL: https://issues.apache.org/jira/browse/IGNITE-17882 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > It does not make sense to have BinaryObject interface in the public API until > IGNITE-14316 is resolved (this ticket should introduce the right interface(s) > at least). > For now, let's just remove BinaryObject. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20342) Rollback transaction for SQL execution issues
[ https://issues.apache.org/jira/browse/IGNITE-20342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20342: - Assignee: Maksim Zhuravkov > Rollback transaction for SQL execution issues > - > > Key: IGNITE-20342 > URL: https://issues.apache.org/jira/browse/IGNITE-20342 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > During execution any data modification we could have runtime error, for > example divide to zero, which lead to cancellation of execution. Right now we > don't rollback transaction for the case and part of modification could be > applied despite of the error. > In ideal word we should be rollbacked just the DML statement, but right now > we don't support savepoint in transaction protocol. So, let's rollback any > type of transaction, explicit and implicit, for any DML statement in case > error is occurred. > Test which could show one of the case of the problem is > org.apache.ignite.internal.sql.api.ItSqlSynchronousApiTest#runtimeErrorInTransaction -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20442) Sql. Extend grammar with transaction related statements.
[
https://issues.apache.org/jira/browse/IGNITE-20442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772157#comment-17772157
]
Maksim Zhuravkov commented on IGNITE-20442:
---
[~zstan], [~jooger] Could you please review my PR?
> Sql. Extend grammar with transaction related statements.
>
>
> Key: IGNITE-20442
> URL: https://issues.apache.org/jira/browse/IGNITE-20442
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to process multistatement queries we need to support the following
> sql grammar to start/finish transactions.
> {code}
> ::=
> START TRANSACTION []
> ::= READ ONLY | READ WRITE
> {code}
> {code}
> ::=
> COMMIT
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
Maksim Zhuravkov created IGNITE-20574: - Summary: Sql. Do not permit to create tables in SYSTEM schema. Key: IGNITE-20574 URL: https://issues.apache.org/jira/browse/IGNITE-20574 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Currently, The SYSTEM schema should only contain only system view objects; adding other objects to this schema should not be allowed. But it is possible to create a table in the SYSTEM schema. We need to disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20574: -- Labels: ignite-3 (was: ) > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20574: -- Fix Version/s: 3.0.0-beta2 > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[
https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20600:
--
Description:
Primary key column update produces an error that contains incorrect error
description:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are not
modifiable.
was:
Primary key column update produces an error that contains incorrect error
description:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are modifiable.
> Sql. Updating primary key column produces an incorrect error message.
> -
>
> Key: IGNITE-20600
> URL: https://issues.apache.org/jira/browse/IGNITE-20600
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Primary key column update produces an error that contains incorrect error
> description:
> {code:java}
> sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
> sql("UPDATE my SET id = 1");
> // Err: Cannot update field "ID". You cannot update key, key fields or val
> field in case the val is a complex type
> {code}
> Update error message so it indicates that primary key columns are not
> modifiable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20593) Sql. Add implicit cast coercion rules to DdlSqlToCommandConverter.
[ https://issues.apache.org/jira/browse/IGNITE-20593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20593: -- Description: In order to make behaviour of types in DDL commands consistent with other SQL statements, we need to update `DdlSqlToCommandConverter` to make it in sync with implicit type coercion rules - if type T1 can be converted from T2, then DEFAULT for type T1 can accept values of type T2. was: At the moment it is not possible to specify a value for default column of UUID data type. The following error is returned - Unknown type [type=UUID]. We can fix this error by allowing to set a varchar value in default constraint from UUID data type (because a varchar can be implicitly converted to UUID). Summary: Sql. Add implicit cast coercion rules to DdlSqlToCommandConverter. (was: Sql. Attempting to specify default value for UUID column results in "Unknown type [type=UUID]") > Sql. Add implicit cast coercion rules to DdlSqlToCommandConverter. > -- > > Key: IGNITE-20593 > URL: https://issues.apache.org/jira/browse/IGNITE-20593 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > In order to make behaviour of types in DDL commands consistent with other SQL > statements, we need to update `DdlSqlToCommandConverter` to make it in sync > with implicit type coercion rules > - if type T1 can be converted from T2, then DEFAULT for type T1 can accept > values of type T2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20593) Sql. Attempting to specify default value for UUID column results in "Unknown type [type=UUID]"
[ https://issues.apache.org/jira/browse/IGNITE-20593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20593: -- Summary: Sql. Attempting to specify default value for UUID column results in "Unknown type [type=UUID]" (was: Sql. Attempting to specify default value for UUID column results in Unknown data type UUID) > Sql. Attempting to specify default value for UUID column results in "Unknown > type [type=UUID]" > -- > > Key: IGNITE-20593 > URL: https://issues.apache.org/jira/browse/IGNITE-20593 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > At the moment it is not possible to specify a value for default column of > UUID data type. The following error is returned - Unknown type [type=UUID]. > We can fix this error by allowing to set a varchar value in default > constraint from UUID data type (because a varchar can be implicitly converted > to UUID). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20593) Sql. Attempting to specify default value for UUID column results in "Unknown type [type=UUID]"
[ https://issues.apache.org/jira/browse/IGNITE-20593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20593: -- Fix Version/s: (was: 3.0.0-beta2) > Sql. Attempting to specify default value for UUID column results in "Unknown > type [type=UUID]" > -- > > Key: IGNITE-20593 > URL: https://issues.apache.org/jira/browse/IGNITE-20593 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > At the moment it is not possible to specify a value for default column of > UUID data type. The following error is returned - Unknown type [type=UUID]. > We can fix this error by allowing to set a varchar value in default > constraint from UUID data type (because a varchar can be implicitly converted > to UUID). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[
https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20600:
--
Description:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are modifiable.
was:
Current the error message is `Cannot update field "ID". You cannot update key,
key fields or val field in case the val is a complex type` is not correcnt, as
it is not the reason why this operation was rejected.
Update error message so it indicates that primary key columns are modifiable.
> Sql. Updating primary key column produces an incorrect error message.
> -
>
> Key: IGNITE-20600
> URL: https://issues.apache.org/jira/browse/IGNITE-20600
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
> sql("UPDATE my SET id = 1");
> // Err: Cannot update field "ID". You cannot update key, key fields or val
> field in case the val is a complex type
> {code}
> Update error message so it indicates that primary key columns are modifiable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20083) Sql. Investigate cost calculation for MAP/REDUCE aggregate.
[ https://issues.apache.org/jira/browse/IGNITE-20083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20083: -- Priority: Minor (was: Major) > Sql. Investigate cost calculation for MAP/REDUCE aggregate. > --- > > Key: IGNITE-20083 > URL: https://issues.apache.org/jira/browse/IGNITE-20083 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > After removing complex objects between MAP/REDUCE phase cost computations > changed and some plans that were expected to choose MAP/REDUCE aggregates are > now choose colocated aggregations or exchange is moved prior to MAP phase, > and not inserted MAP/REDUCE phases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[
https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20600:
--
Description:
Primary key column update produces an error that contains incorrect error
description:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are modifiable.
was:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are modifiable.
> Sql. Updating primary key column produces an incorrect error message.
> -
>
> Key: IGNITE-20600
> URL: https://issues.apache.org/jira/browse/IGNITE-20600
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Primary key column update produces an error that contains incorrect error
> description:
> {code:java}
> sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
> sql("UPDATE my SET id = 1");
> // Err: Cannot update field "ID". You cannot update key, key fields or val
> field in case the val is a complex type
> {code}
> Update error message so it indicates that primary key columns are modifiable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[ https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20600: -- Labels: ignite-3 (was: ) > Sql. Updating primary key column produces an incorrect error message. > - > > Key: IGNITE-20600 > URL: https://issues.apache.org/jira/browse/IGNITE-20600 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Current the error message is `Cannot update field "ID". You cannot update > key, key fields or val field in case the val is a complex type` is not > correcnt, as it is not the reason why this operation was rejected. > Update error message so it indicates that primary key columns are modifiable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
Maksim Zhuravkov created IGNITE-20600: - Summary: Sql. Updating primary key column produces an incorrect error message. Key: IGNITE-20600 URL: https://issues.apache.org/jira/browse/IGNITE-20600 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 Current the error message is `Cannot update field "ID". You cannot update key, key fields or val field in case the val is a complex type` is not correcnt, as it is not the reason why this operation was rejected. Update error message so it indicates that primary key columns are modifiable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
