[jira] [Assigned] (IGNITE-16987) JDBC driver for 3.0: connection channel usage refactoring
[ https://issues.apache.org/jira/browse/IGNITE-16987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-16987: - Assignee: Vladimir Ermakov > JDBC driver for 3.0: connection channel usage refactoring > - > > Key: IGNITE-16987 > URL: https://issues.apache.org/jira/browse/IGNITE-16987 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > 1 part: > In 3.0 JDBC all queries go through ReliableChannel, which can do reconnects, > retries, etc. > This is wrong for things like SQL_NEXT, SQL_QUERY_META, SQL_CURSOR_CLOSE, and > so on, which should be executed strictly on the same connection. To do this, > there's PayloadInputChannel.clientChannel , which you can keep when a > query/cursor is initiated. > > 2 part: > We have to close resources on the server after client is disconnected. To do > this, there is a ClientResourceRegistry , it is cleared when you disconnect. > If that doesn't work, see ClientInboundMessageHandler#channelInactive -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17034) Thin 3.0: Rename JDBC packages and classes to separate them from Ignite SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542212#comment-17542212 ] Vladimir Ermakov commented on IGNITE-17034: --- LGTM > Thin 3.0: Rename JDBC packages and classes to separate them from Ignite SQL > API > --- > > Key: IGNITE-17034 > URL: https://issues.apache.org/jira/browse/IGNITE-17034 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql, thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > Rename client operation names, request handlers, and their packages from Sql > to Jdbc. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16987) JDBC driver for 3.0: connection channel usage refactoring
[ https://issues.apache.org/jira/browse/IGNITE-16987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16987: -- Remaining Estimate: (was: 5m) Original Estimate: (was: 5m) > JDBC driver for 3.0: connection channel usage refactoring > - > > Key: IGNITE-16987 > URL: https://issues.apache.org/jira/browse/IGNITE-16987 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > 1 part: > In 3.0 JDBC all queries go through ReliableChannel, which can do reconnects, > retries, etc. > This is wrong for things like SQL_NEXT, SQL_QUERY_META, SQL_CURSOR_CLOSE, and > so on, which should be executed strictly on the same connection. To do this, > there's PayloadInputChannel.clientChannel , which you can keep when a > query/cursor is initiated. > > 2 part: > We have to close resources on the server after client is disconnected. To do > this, there is a ClientResourceRegistry , it is cleared when you disconnect. > If that doesn't work, see ClientInboundMessageHandler#channelInactive -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16987) JDBC driver for 3.0: connection channel usage refactoring
[ https://issues.apache.org/jira/browse/IGNITE-16987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16987: -- Remaining Estimate: 5m Original Estimate: 5m > JDBC driver for 3.0: connection channel usage refactoring > - > > Key: IGNITE-16987 > URL: https://issues.apache.org/jira/browse/IGNITE-16987 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > Original Estimate: 5m > Remaining Estimate: 5m > > 1 part: > In 3.0 JDBC all queries go through ReliableChannel, which can do reconnects, > retries, etc. > This is wrong for things like SQL_NEXT, SQL_QUERY_META, SQL_CURSOR_CLOSE, and > so on, which should be executed strictly on the same connection. To do this, > there's PayloadInputChannel.clientChannel , which you can keep when a > query/cursor is initiated. > > 2 part: > We have to close resources on the server after client is disconnected. To do > this, there is a ClientResourceRegistry , it is cleared when you disconnect. > If that doesn't work, see ClientInboundMessageHandler#channelInactive -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16987) JDBC driver for 3.0: connection channel usage refactoring
Vladimir Ermakov created IGNITE-16987: - Summary: JDBC driver for 3.0: connection channel usage refactoring Key: IGNITE-16987 URL: https://issues.apache.org/jira/browse/IGNITE-16987 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov 1 part: In 3.0 JDBC all queries go through ReliableChannel, which can do reconnects, retries, etc. This is wrong for things like SQL_NEXT, SQL_QUERY_META, SQL_CURSOR_CLOSE, and so on, which should be executed strictly on the same connection. To do this, there's PayloadInputChannel.clientChannel , which you can keep when a query/cursor is initiated. 2 part: We have to close resources on the server after client is disconnected. To do this, there is a ClientResourceRegistry , it is cleared when you disconnect. If that doesn't work, see ClientInboundMessageHandler#channelInactive -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-14636) Calcite engine. Support for LISTAGG (aka GROUP_CONCAT, STRING_AGG) aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528086#comment-17528086
]
Vladimir Ermakov commented on IGNITE-14636:
---
[~ivandasch] I don't mind if you assign and finish the task.
> Calcite engine. Support for LISTAGG (aka GROUP_CONCAT, STRING_AGG) aggregate
> function
> -
>
> Key: IGNITE-14636
> URL: https://issues.apache.org/jira/browse/IGNITE-14636
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Tests:
> {{aggregate/aggregates/test_aggregate_types.test}}
> {{aggregate/aggregates/test_aggregate_types_scalar.test}}
> {{aggregate/aggregates/test_distinct_string_agg.test_ignore}}
> {{aggregate/aggregates/test_string_agg.test_ignore}}
> {{aggregate/aggregates/test_string_agg_big.test_ignore}}
> {{aggregate/aggregates/test_string_agg_many_groups.test_slow_ignored}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-16683) Ignite-3 enable jdbc tests
[
https://issues.apache.org/jira/browse/IGNITE-16683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511720#comment-17511720
]
Vladimir Ermakov commented on IGNITE-16683:
---
LGTM!
> Ignite-3 enable jdbc tests
> --
>
> Key: IGNITE-16683
> URL: https://issues.apache.org/jira/browse/IGNITE-16683
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_2077.log.zip,
> _Integration_Tests_Module_Runner_2083.log.zip, screenshot-1.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For now tests disabled under IGNITE-15655, seems we can enable them.
> Locally it`s all ok there.
> ---
> After enabling tests raised additional problem (seems differ than described
> in IGNITE-15655) [1] Tests from ItJdbcStatementSelfTest randomly failed, with
> :
> *IgniteInternalException: Failed to INSERT some keys because they are already
> in cache*
> Possibly this is due to gc pause, check for example in logs:
> {noformat}
> [13:29:17]W: [org.apache.ignite:ignite-runner] 2022-03-14
> 13:29:17:381 +0300 [INFO][Thread-58290][RaftGroupService] Start the
> RaftGroupService successfully <48b22e85-6917-47e1-b9ad-
> bb4a26516dc5_part_19/172.17.0.6:47500>
> [13:29:17]W: [org.apache.ignite:ignite-runner] 2022-03-14
> 13:29:17:682 +0300
> [INFO][%ItJdbcStatementSelfTest_null_47500%JRaft-FSMCaller-Disruptor-_stripe_18-0][StateMachineAdapter]
> onLeaderStart: term=1.
> [13:30:40]W: [org.apache.ignite:ignite-runner] 2022-03-14
> 13:30:32:060 +0300
> [WARNING][%ItJdbcStatementSelfTest_null_47500%sqlExec-2][QueryTaskExecutorImpl]
> Uncaught exception
> [13:30:40]W: [org.apache.ignite:ignite-runner] class
> org.apache.ignite.lang.IgniteInternalException: Unexpected exception
> {noformat}
> I suppose that *public void afterEach()* not raised due to gc and further
> start become on already filled db.
> !screenshot-1.png!
> [1]
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRunner?branch=pull%2F718=builds
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16468) Extend test coverage for RecordBinaryView
[ https://issues.apache.org/jira/browse/IGNITE-16468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-16468: - Assignee: Vladimir Ermakov > Extend test coverage for RecordBinaryView > - > > Key: IGNITE-16468 > URL: https://issues.apache.org/jira/browse/IGNITE-16468 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3, tech-debt > > As of now we have few tests at RecordBinaryViewOperationsTest for simple > cases. Let’s think about expanding the test coverage at least for > get/put/removeAll. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16219) JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix
[ https://issues.apache.org/jira/browse/IGNITE-16219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504980#comment-17504980 ] Vladimir Ermakov commented on IGNITE-16219: --- LGTM > JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix > - > > Key: IGNITE-16219 > URL: https://issues.apache.org/jira/browse/IGNITE-16219 > Project: Ignite > Issue Type: Bug > Components: jdbc, sql >Reporter: Vladimir Ermakov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > ItJdbcJoinsSelfTest1.testJoin runs correctly in local, but in teamcity > java.lang.AssertionError is appeared. Should be investigated. Logs: > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRunner/6343350 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16620) Flacky test LocalSnapshotCopierTest#testInterrupt
Vladimir Ermakov created IGNITE-16620:
-
Summary: Flacky test LocalSnapshotCopierTest#testInterrupt
Key: IGNITE-16620
URL: https://issues.apache.org/jira/browse/IGNITE-16620
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Ermakov
org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotCopierTest#testInterrupt
test seems flacky.
To reproduce: run the test cyclically until it failure.
Reason:
Code in LocalSnashotCopier#loadMetaTable
{code:java}
if (!session.status().isOk() && isOk()) {code}
doesn't expect that the LocalSnashotCopier object's internal state (which is
checked in isOk() method) could be changed by another thread, and is set to
interrupted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16292) Calcite. Unstable alterTableServerAndClient test.
[
https://issues.apache.org/jira/browse/IGNITE-16292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16292:
-
Assignee: (was: Vladimir Ermakov)
> Calcite. Unstable alterTableServerAndClient test.
> -
>
> Key: IGNITE-16292
> URL: https://issues.apache.org/jira/browse/IGNITE-16292
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required
>
> alterTableServerAndClient test periodically fails with:
> {code:java}
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableDescriptorImpl.rowType(CacheTableDescriptorImpl.java:550)
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableImpl.getRowType(CacheTableImpl.java:78)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.deriveRowType(ProjectableFilterableTableScan.java:147)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at org.apache.calcite.rel.SingleRel.deriveRowType(SingleRel.java:89)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:160)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:110)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteSender.accept(IgniteSender.java:100)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:658)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:673)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeFragment(ExecutionServiceImpl.java:591)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:652)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$init$2(ExecutionServiceImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:276)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:254)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16292) Calcite. Unstable alterTableServerAndClient test.
[
https://issues.apache.org/jira/browse/IGNITE-16292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16292:
-
Assignee: Vladimir Ermakov
> Calcite. Unstable alterTableServerAndClient test.
> -
>
> Key: IGNITE-16292
> URL: https://issues.apache.org/jira/browse/IGNITE-16292
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: calcite, calcite2-required
>
> alterTableServerAndClient test periodically fails with:
> {code:java}
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableDescriptorImpl.rowType(CacheTableDescriptorImpl.java:550)
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableImpl.getRowType(CacheTableImpl.java:78)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.deriveRowType(ProjectableFilterableTableScan.java:147)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at org.apache.calcite.rel.SingleRel.deriveRowType(SingleRel.java:89)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:160)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:110)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteSender.accept(IgniteSender.java:100)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:658)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:673)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeFragment(ExecutionServiceImpl.java:591)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:652)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$init$2(ExecutionServiceImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:276)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:254)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16489) Calcite integration. MERGE statement support: merge to 3.0
Vladimir Ermakov created IGNITE-16489: - Summary: Calcite integration. MERGE statement support: merge to 3.0 Key: IGNITE-16489 URL: https://issues.apache.org/jira/browse/IGNITE-16489 Project: Ignite Issue Type: Improvement Components: sql Reporter: Vladimir Ermakov Fix For: 3.0.0-alpha5 Adopt the MERGE statement patch ([IGNITE-12695|https://issues.apache.org/jira/browse/IGNITE-12695]) for the Ignite 3.0. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16201) JDBC driver for 3.0: Batch execution.
[ https://issues.apache.org/jira/browse/IGNITE-16201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-16201: - Assignee: Vladimir Ermakov > JDBC driver for 3.0: Batch execution. > - > > Key: IGNITE-16201 > URL: https://issues.apache.org/jira/browse/IGNITE-16201 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > Let's implement batch execution in JDBC driver. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16328) Sql. Correlated queries with ORDER and LIMIT can't be planned. AssertionError: Input not sorted for some ORDER BY containing requests.
[ https://issues.apache.org/jira/browse/IGNITE-16328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485332#comment-17485332 ] Vladimir Ermakov commented on IGNITE-16328: --- [~zstan] , LGTM too. > Sql. Correlated queries with ORDER and LIMIT can't be planned. > AssertionError: Input not sorted for some ORDER BY containing requests. > -- > > Key: IGNITE-16328 > URL: https://issues.apache.org/jira/browse/IGNITE-16328 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite3-required, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Merge IGNITE-15992, IGNITE-16138 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16389) Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop
[ https://issues.apache.org/jira/browse/IGNITE-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484862#comment-17484862 ] Vladimir Ermakov commented on IGNITE-16389: --- [~zstan] LGTM! > Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop > - > > Key: IGNITE-16389 > URL: https://issues.apache.org/jira/browse/IGNITE-16389 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Evgeny Stanilovsky >Priority: Blocker > Labels: ignite-3 > Attachments: image (1).png > > > Test > org.apache.ignite.internal.sql.engine.StopCalciteModuleTest#testStopQueryOnNodeStop > is flacky. To reproduce: repeat the test until NPE appears. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16201) JDBC driver for 3.0: Batch execution.
[ https://issues.apache.org/jira/browse/IGNITE-16201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16201: -- Environment: (was: Let's implement batch execution in JDBC driver.) > JDBC driver for 3.0: Batch execution. > - > > Key: IGNITE-16201 > URL: https://issues.apache.org/jira/browse/IGNITE-16201 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > Let's implement batch execution in JDBC driver. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16201) JDBC driver for 3.0: Batch execution.
[ https://issues.apache.org/jira/browse/IGNITE-16201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16201: -- Description: Let's implement batch execution in JDBC driver. > JDBC driver for 3.0: Batch execution. > - > > Key: IGNITE-16201 > URL: https://issues.apache.org/jira/browse/IGNITE-16201 > Project: Ignite > Issue Type: New Feature > Components: jdbc > Environment: Let's implement batch execution in JDBC driver. >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > Let's implement batch execution in JDBC driver. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16432) JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction support is done
[ https://issues.apache.org/jira/browse/IGNITE-16432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16432: -- Component/s: sql Labels: ignite-3 (was: ) > JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction > support is done > -- > > Key: IGNITE-16432 > URL: https://issues.apache.org/jira/browse/IGNITE-16432 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > It is necessary to add "COMMIT" and "ROLLBACK" calls in JdbcConnection#commit > and JdbcConnection#rollback methods after transaction support for sql engine > is done. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16432) JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction support is done
[ https://issues.apache.org/jira/browse/IGNITE-16432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16432: -- Description: It is necessary to add "COMMIT" and "ROLLBACK" calls in JdbcConnection#commit and JdbcConnection#rollback methods after transaction support for sql engine is done. > JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction > support is done > -- > > Key: IGNITE-16432 > URL: https://issues.apache.org/jira/browse/IGNITE-16432 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > > It is necessary to add "COMMIT" and "ROLLBACK" calls in JdbcConnection#commit > and JdbcConnection#rollback methods after transaction support for sql engine > is done. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16432) JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction support is done
Vladimir Ermakov created IGNITE-16432: - Summary: JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction support is done Key: IGNITE-16432 URL: https://issues.apache.org/jira/browse/IGNITE-16432 Project: Ignite Issue Type: Improvement Reporter: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16432) JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction support is done
[ https://issues.apache.org/jira/browse/IGNITE-16432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-16432: - Assignee: Vladimir Ermakov > JDBC driver for 3.0: Call COMMIT and ROLLBACK queries when sql transaction > support is done > -- > > Key: IGNITE-16432 > URL: https://issues.apache.org/jira/browse/IGNITE-16432 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
[ https://issues.apache.org/jira/browse/IGNITE-16422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484588#comment-17484588 ] Vladimir Ermakov commented on IGNITE-16422: --- [~amashenkov] [~zstan] please, take a look. > Calcite: ArrayOutOfBoundException on row update > --- > > Key: IGNITE-16422 > URL: https://issues.apache.org/jira/browse/IGNITE-16422 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Blocker > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > After IGNITE-16296 new bug with row update logic is appeared. > To reproduce run ItJdbcStatementSelfTest#testExecuteUpdate(). > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
[ https://issues.apache.org/jira/browse/IGNITE-16422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16422: -- Description: After IGNITE-16296 new bug with row update logic is appeared. To reproduce run ItJdbcStatementSelfTest#testExecuteUpdate(). > Calcite: ArrayOutOfBoundException on row update > --- > > Key: IGNITE-16422 > URL: https://issues.apache.org/jira/browse/IGNITE-16422 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Critical > Labels: ignite-3 > > After IGNITE-16296 new bug with row update logic is appeared. > To reproduce run ItJdbcStatementSelfTest#testExecuteUpdate(). > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
[ https://issues.apache.org/jira/browse/IGNITE-16422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16422: -- Priority: Critical (was: Major) > Calcite: ArrayOutOfBoundException on row update > --- > > Key: IGNITE-16422 > URL: https://issues.apache.org/jira/browse/IGNITE-16422 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Critical > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16422) Calcite: ArrayOutOfBoundException on row update
Vladimir Ermakov created IGNITE-16422: - Summary: Calcite: ArrayOutOfBoundException on row update Key: IGNITE-16422 URL: https://issues.apache.org/jira/browse/IGNITE-16422 Project: Ignite Issue Type: Bug Components: sql Reporter: Vladimir Ermakov Assignee: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16411) NPE in org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns
[
https://issues.apache.org/jira/browse/IGNITE-16411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16411:
-
Assignee: Vladimir Ermakov
> NPE in org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns
> --
>
> Key: IGNITE-16411
> URL: https://issues.apache.org/jira/browse/IGNITE-16411
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Fedor Malchikov
>Assignee: Vladimir Ermakov
>Priority: Blocker
> Labels: ignite-3
>
> {code:java}
> [INFO ] 2022-01-26 18:39:46,803 [main] com.oltpbenchmark.DBWorkload main -
> Finished creating new YCSB database...
> Exception in thread "main" java.util.concurrent.CompletionException: class
> org.apache.ignite.client.IgniteClientException: null
> at
> java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412)
> at
> java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2044)
> at
> org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns(JdbcDatabaseMetadata.java:975)
> at com.oltpbenchmark.util.SQLUtil.getCatalogDirect(SQLUtil.java:458)
> at com.oltpbenchmark.util.SQLUtil.getCatalog(SQLUtil.java:411)
> at
> com.oltpbenchmark.api.BenchmarkModule.refreshCatalog(BenchmarkModule.java:233)
> at com.oltpbenchmark.DBWorkload.main(DBWorkload.java:416)
> Caused by: class org.apache.ignite.client.IgniteClientException: null
> at
> org.apache.ignite.internal.client.TcpClientChannel.convertException(TcpClientChannel.java:241)
> at
> org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:197)
> at
> org.apache.ignite.internal.client.TcpClientChannel.serviceAsync(TcpClientChannel.java:143)
> at
> org.apache.ignite.internal.client.ReliableChannel.handleServiceAsync(ReliableChannel.java:188)
> at
> org.apache.ignite.internal.client.ReliableChannel.serviceAsync(ReliableChannel.java:144)
> at
> org.apache.ignite.internal.client.TcpIgniteClient.sendRequestAsync(TcpIgniteClient.java:145)
> at
> org.apache.ignite.internal.client.query.JdbcClientQueryEventHandler.columnsMetaAsync(JdbcClientQueryEventHandler.java:103)
> at
> org.apache.ignite.internal.jdbc.JdbcDatabaseMetadata.getColumns(JdbcDatabaseMetadata.java:974)
> ... 4 more
> Caused by: java.lang.NullPointerException
> at io.netty.buffer.ByteBufUtil.utf8MaxBytes(ByteBufUtil.java:948)
> at
> org.apache.ignite.internal.client.proto.ClientMessagePacker.packString(ClientMessagePacker.java:292)
> at
> org.apache.ignite.client.proto.query.event.JdbcMetaColumnsRequest.writeBinary(JdbcMetaColumnsRequest.java:89)
> at
> org.apache.ignite.internal.client.TcpIgniteClient.lambda$sendRequestAsync$1(TcpIgniteClient.java:145)
> at
> org.apache.ignite.internal.client.TcpClientChannel.send(TcpClientChannel.java:182)
> ... 10 more {code}
> after create table:
> {code:sql}
> CREATE TABLE usertable (
> ycsb_key int PRIMARY KEY,
> field1 varchar(100),
> field2 varchar(100),
> field3 varchar(100),
> field4 varchar(100),
> field5 varchar(100),
> field6 varchar(100),
> field7 varchar(100),
> field8 varchar(100),
> field9 varchar(100),
> field10 varchar(100)
> );{code}
> Reproduced on:
> {code:java}
> private static AbstractCatalog getCatalogDirect(DatabaseType databaseType,
> Connection connection) throws SQLException {
> DatabaseMetaData md = connection.getMetaData();
> String separator = md.getIdentifierQuoteString();
> String catalog = connection.getCatalog();
> String schema = connection.getSchema();
> Map tables = new HashMap<>();
> List excludedColumns = new ArrayList<>();
> try (ResultSet table_rs = md.getTables(catalog, schema, null, new
> String[]{"TABLE"})) {
> while (table_rs.next()) {
> String table_type = table_rs.getString("TABLE_TYPE");
> if (!table_type.equalsIgnoreCase("TABLE")) {
> continue;
> }
> String table_name = table_rs.getString("TABLE_NAME");
> Table catalog_tbl = new Table(table_name, separator);
> try (ResultSet col_rs = md.getColumns(catalog, schema,
> table_name, null)) {
> while (col_rs.next()) {
> String col_name = col_rs.getString("COLUMN_NAME");
> if (excludedColumns.contains(col_name.toUpperCase())) {
> LOG.debug("found excluded column [{}] for in database
> type [{}]. Skipping...", col_name, databaseType);
> continue;
> }
> int col_type = col_rs.getInt("DATA_TYPE");
> Integer col_size =
[jira] [Commented] (IGNITE-16269) JDBC. Support for Statement#maxRows
[
https://issues.apache.org/jira/browse/IGNITE-16269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482321#comment-17482321
]
Vladimir Ermakov commented on IGNITE-16269:
---
[~korlov] could you please take a look?
> JDBC. Support for Statement#maxRows
> ---
>
> Key: IGNITE-16269
> URL: https://issues.apache.org/jira/browse/IGNITE-16269
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: ignite-3
>
> A {{maxRows}} attribute is stored into statement and passed to the
> QueryExecuteRequest, but ignored on the server side.
> Let's add support for this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16269) JDBC. Support for Statement#maxRows
[
https://issues.apache.org/jira/browse/IGNITE-16269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16269:
-
Assignee: Vladimir Ermakov
> JDBC. Support for Statement#maxRows
> ---
>
> Key: IGNITE-16269
> URL: https://issues.apache.org/jira/browse/IGNITE-16269
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: ignite-3
>
> A {{maxRows}} attribute is stored into statement and passed to the
> QueryExecuteRequest, but ignored on the server side.
> Let's add support for this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16268) JDBC. Validation of statement type should be done before its execution
[
https://issues.apache.org/jira/browse/IGNITE-16268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16268:
-
Assignee: Vladimir Ermakov
> JDBC. Validation of statement type should be done before its execution
> --
>
> Key: IGNITE-16268
> URL: https://issues.apache.org/jira/browse/IGNITE-16268
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: ignite-3
>
> Currently, it's possible to execute DML statement such as INSERT, UPDATE, or
> DELETE with {{Statement#executeQuery}} method. The statement will be
> executed, and exception will be thrown after result of the execution will be
> received.
> {code:java}
> class JdbcStatement {
> public ResultSet executeQuery(String sql) throws SQLException {
> ...
> ResultSet rs = getResultSet();
> if (rs == null) {
> throw new SQLException("The query isn't SELECT query: " + sql,
> SqlStateCode.PARSING_EXCEPTION);
> }
> ...
> }
> public ResultSet getResultSet() throws SQLException {
> ...
> JdbcResultSet rs = resSets.get(curRes);
> if (!rs.isQuery()) {
> return null;
> }
> ...
> }
> {code}
> Let's validate the type of the statement before its execution.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16389) Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop
[ https://issues.apache.org/jira/browse/IGNITE-16389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16389: -- Attachment: image (1).png > Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop > - > > Key: IGNITE-16389 > URL: https://issues.apache.org/jira/browse/IGNITE-16389 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Priority: Blocker > Labels: ignite-3 > Attachments: image (1).png > > > Test > org.apache.ignite.internal.sql.engine.StopCalciteModuleTest#testStopQueryOnNodeStop > is flacky. To reproduce: repeat the test until NPE appears. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16389) Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop
Vladimir Ermakov created IGNITE-16389: - Summary: Fix flacky test StopCalciteModuleTest#testStopQueryOnNodeStop Key: IGNITE-16389 URL: https://issues.apache.org/jira/browse/IGNITE-16389 Project: Ignite Issue Type: Bug Components: sql Reporter: Vladimir Ermakov Test org.apache.ignite.internal.sql.engine.StopCalciteModuleTest#testStopQueryOnNodeStop is flacky. To reproduce: repeat the test until NPE appears. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16192) Calcite. Support hidden columns
[ https://issues.apache.org/jira/browse/IGNITE-16192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-16192: - Assignee: Vladimir Ermakov > Calcite. Support hidden columns > --- > > Key: IGNITE-16192 > URL: https://issues.apache.org/jira/browse/IGNITE-16192 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Vladimir Ermakov >Priority: Critical > Labels: calcite2-required, calcite3-required, ignite-3 > > We should have ability to hide some columns. At first glance it's *_key* > column. It really important for autogenerated PK. > Such columns couldn't be accessed for 'select * ' query, but available for > explicit use in select statement. > Another example of hidden column is Oracle *rownum*. > Also another databases (Oracle, SQLSERVER, MySQL) have support hidden > (invisible) columns which could be created user explicitly and amend the > visibility through ALTER statement. Maybe we should consider possible > extension it for future to support one. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16311) Revise and remove resolved tickets (IGNITE-15188,IGNITE-15443) mentions in code
[ https://issues.apache.org/jira/browse/IGNITE-16311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477836#comment-17477836 ] Vladimir Ermakov commented on IGNITE-16311: --- [~amashenkov], could you please take a look? > Revise and remove resolved tickets (IGNITE-15188,IGNITE-15443) mentions in > code > --- > > Key: IGNITE-16311 > URL: https://issues.apache.org/jira/browse/IGNITE-16311 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > Tickets IGNITE-15188,IGNITE-15443 are marked as resolved, but still have > mentions in code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15983) Regression when using SELECT (EXISTS (...)) part 2
[
https://issues.apache.org/jira/browse/IGNITE-15983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477831#comment-17477831
]
Vladimir Ermakov commented on IGNITE-15983:
---
[~korlov], could you please take a look?
> Regression when using SELECT (EXISTS (...)) part 2
> --
>
> Key: IGNITE-15983
> URL: https://issues.apache.org/jira/browse/IGNITE-15983
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the task https://issues.apache.org/jira/browse/IGNITE-14354 erroneous
> queries were not fully corrected.
> So, a query like
> {code:java}
> CREATE TABLE t (i int PRIMARY KEY, j int);
> SELECT (EXISTS (SELECT 1 FROM t WHERE t.i = 1)); {code}
> now passes, when a query
> {code:java}
> CREATE TABLE t (i int PRIMARY KEY, j int);
> SELECT (EXISTS (SELECT i FROM t WHERE t.i = 1)); {code}
> still fails.
> The original cause of the error must be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16311) Revise and remove resolved tickets (IGNITE-15188,IGNITE-15443) mentions in code
[ https://issues.apache.org/jira/browse/IGNITE-16311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-16311: - Assignee: Vladimir Ermakov > Revise and remove resolved tickets (IGNITE-15188,IGNITE-15443) mentions in > code > --- > > Key: IGNITE-16311 > URL: https://issues.apache.org/jira/browse/IGNITE-16311 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > Tickets IGNITE-15188,IGNITE-15443 are marked as resolved, but still have > mentions in code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16311) Revise and remove resolved tickets (IGNITE-15188,IGNITE-15443) mentions in code
Vladimir Ermakov created IGNITE-16311: - Summary: Revise and remove resolved tickets (IGNITE-15188,IGNITE-15443) mentions in code Key: IGNITE-16311 URL: https://issues.apache.org/jira/browse/IGNITE-16311 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ermakov Tickets IGNITE-15188,IGNITE-15443 are marked as resolved, but still have mentions in code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15810) Rename ignite-calcite module to ignite-sql-engine at Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-15810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15810: - Assignee: Vladimir Ermakov > Rename ignite-calcite module to ignite-sql-engine at Ignite 3.0 > > > Key: IGNITE-15810 > URL: https://issues.apache.org/jira/browse/IGNITE-15810 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Vladimir Ermakov >Priority: Major > Labels: calcite, calcite3-required, ignite-3 > > Let's rename the ignite-calcite module to ignite-sql-engine at Ignite 3.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16219) JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix
[ https://issues.apache.org/jira/browse/IGNITE-16219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov updated IGNITE-16219: -- Component/s: jdbc Labels: ignite-3 (was: ) > JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix > - > > Key: IGNITE-16219 > URL: https://issues.apache.org/jira/browse/IGNITE-16219 > Project: Ignite > Issue Type: Bug > Components: jdbc >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > ItJdbcJoinsSelfTest1.testJoin runs correctly in local, but in teamcity > java.lang.AssertionError is appeared. Should be investigated. Logs: > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRunner/6343350 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16219) JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix
Vladimir Ermakov created IGNITE-16219: - Summary: JDBC driver for 3.0: ItJdbcJoinsSelfTest test fix Key: IGNITE-16219 URL: https://issues.apache.org/jira/browse/IGNITE-16219 Project: Ignite Issue Type: Bug Reporter: Vladimir Ermakov ItJdbcJoinsSelfTest1.testJoin runs correctly in local, but in teamcity java.lang.AssertionError is appeared. Should be investigated. Logs: https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRunner/6343350 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16207) JDBC driver for 3.0: Calcite throws class cast exception
Vladimir Ermakov created IGNITE-16207: - Summary: JDBC driver for 3.0: Calcite throws class cast exception Key: IGNITE-16207 URL: https://issues.apache.org/jira/browse/IGNITE-16207 Project: Ignite Issue Type: New Feature Components: jdbc Reporter: Vladimir Ermakov Calcite throws java.lang.ClassCastException: class java.lang.String cannot be cast to class java.lang.Integer (java.lang.String and java.lang.Integer are in module java.base of loader 'bootstrap') when ItJdbcComplexDmlDdlSelfTest#testCreateSelectDrop() test running after ItJdbcInsertStatementSelfTest#testDuplicateKeys(). However, single run passed correctly. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16205) Calcite integration: Add JDBC tests when query cancelation is supported.
Vladimir Ermakov created IGNITE-16205: - Summary: Calcite integration: Add JDBC tests when query cancelation is supported. Key: IGNITE-16205 URL: https://issues.apache.org/jira/browse/IGNITE-16205 Project: Ignite Issue Type: New Feature Components: jdbc Reporter: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16204) Calcite integration. Add JDBC tests when INDEX support is appeared
Vladimir Ermakov created IGNITE-16204: - Summary: Calcite integration. Add JDBC tests when INDEX support is appeared Key: IGNITE-16204 URL: https://issues.apache.org/jira/browse/IGNITE-16204 Project: Ignite Issue Type: New Feature Components: jdbc Reporter: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16203) JDBC driver for 3.0: Parameter metadata.
Vladimir Ermakov created IGNITE-16203: - Summary: JDBC driver for 3.0: Parameter metadata. Key: IGNITE-16203 URL: https://issues.apache.org/jira/browse/IGNITE-16203 Project: Ignite Issue Type: New Feature Components: jdbc Reporter: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16201) JDBC driver for 3.0: Batch execution.
Vladimir Ermakov created IGNITE-16201: - Summary: JDBC driver for 3.0: Batch execution. Key: IGNITE-16201 URL: https://issues.apache.org/jira/browse/IGNITE-16201 Project: Ignite Issue Type: New Feature Components: jdbc Environment: Let's implement batch execution in JDBC driver. Reporter: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16057) Second read of array field from BinaryObject fail
[
https://issues.apache.org/jira/browse/IGNITE-16057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-16057:
--
Description:
Second read of array field fail and read some garbage.
This happen because when object read with handle stream position don't move to
the end of already deserialized object.
So second array element is just random bytes from the middle of the stream.
Root cause:
In the previous patch, handlers were added to allow to cache values that have
already been read. Handles were added for objects, but not for arrays. When
reading an array, it first creates a new array instance and then reads the
objects in that array in the order in which they appear in the array.
The problem is that when an object is read, the position of the next object in
the binary array is set. This way we can always continue reading objects in
order. But now we just return a cached object, and don't calculate next
position. So we read garbage, or we get an error when we try to read the next
item because we don't know its real position.
Siggestion fix:
We need to add handle logic when reading arrays. Then when you try to read the
array again, a cached copy will be returned.
It is also necessary to consider the deserialization flag. If it is set, it is
necessary to re-read the array and fill it with deserialized copies of objects.
BinaryObjectBuilderAdditionalSelfTest
{code:java}
/** */
@Test
public void testArrayFieldSeveralRead() throws Exception {
try (Ignite ignite = startGrid(1)) {
TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
TestClass1()};
BinaryObject arrObj = ignite.binary().toBinary(new
TestClsWithArray(expArr));
for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
arrObj =
ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
expArr).build();
for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
}
finally {
clearBinaryMeta();
}
}
/** Test class with array. */
public static class TestClsWithArray {
/** */
private final Object[] arr;
/** */
public TestClsWithArray(TestClass1[] arr) {
this.arr = arr;
}
}
{code}
was:
Second read of array field fail and read some garbage.
This happen because when object read with handle stream position don't move to
the end of already deserialized object.
So second array element is just random bytes from the middle of the stream.
BinaryObjectBuilderAdditionalSelfTest
{code:java}
/** */
@Test
public void testArrayFieldSeveralRead() throws Exception {
try (Ignite ignite = startGrid(1)) {
TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
TestClass1()};
BinaryObject arrObj = ignite.binary().toBinary(new
TestClsWithArray(expArr));
for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
arrObj =
ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
expArr).build();
for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
}
finally {
clearBinaryMeta();
}
}
/** Test class with array. */
public static class TestClsWithArray {
/** */
private final Object[] arr;
/** */
public TestClsWithArray(TestClass1[] arr) {
this.arr = arr;
}
}
{code}
> Second read of array field from BinaryObject fail
> -
>
> Key: IGNITE-16057
> URL: https://issues.apache.org/jira/browse/IGNITE-16057
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Vladimir Ermakov
>Priority: Blocker
> Labels: ise
>
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream.
> Root cause:
> In the previous patch, handlers were added to allow to cache values that have
> already been read. Handles were added for objects, but not for arrays. When
> reading an array, it first creates a new array instance and then reads the
> objects in that array in the order in which they appear in the array.
> The
[jira] [Commented] (IGNITE-16057) Second read of array field from BinaryObject fail
[
https://issues.apache.org/jira/browse/IGNITE-16057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457064#comment-17457064
]
Vladimir Ermakov commented on IGNITE-16057:
---
Hello [~nizhikov] [~tledkov-gridgain]! Could you please have a look at the
patch?
> Second read of array field from BinaryObject fail
> -
>
> Key: IGNITE-16057
> URL: https://issues.apache.org/jira/browse/IGNITE-16057
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Vladimir Ermakov
>Priority: Blocker
> Labels: ise
>
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream.
> BinaryObjectBuilderAdditionalSelfTest
> {code:java}
> /** */
> @Test
> public void testArrayFieldSeveralRead() throws Exception {
> try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }
> finally {
> clearBinaryMeta();
> }
> }
> /** Test class with array. */
> public static class TestClsWithArray {
> /** */
> private final Object[] arr;
> /** */
> public TestClsWithArray(TestClass1[] arr) {
> this.arr = arr;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-16062) Support binary HANLDEs: Unable read object array twice.
[
https://issues.apache.org/jira/browse/IGNITE-16062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov resolved IGNITE-16062.
---
Resolution: Duplicate
> Support binary HANLDEs: Unable read object array twice.
> ---
>
> Key: IGNITE-16062
> URL: https://issues.apache.org/jira/browse/IGNITE-16062
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
>
> "Looks like this commit introduce a blocker.
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream."
>
> Reproducer:
> {code:java}
> /** */
> @Test
> public void testArrayFieldSeveralRead() throws Exception {
> try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }
> finally {
> clearBinaryMeta();
> }
> }
> /** Test class with array. */
> public static class TestClsWithArray {
> /** */
> private final Object[] arr;
> /** */
> public TestClsWithArray(TestClass1[] arr) {
> this.arr = arr;
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16057) Second read of array field from BinaryObject fail
[
https://issues.apache.org/jira/browse/IGNITE-16057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16057:
-
Assignee: Vladimir Ermakov
> Second read of array field from BinaryObject fail
> -
>
> Key: IGNITE-16057
> URL: https://issues.apache.org/jira/browse/IGNITE-16057
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Vladimir Ermakov
>Priority: Blocker
> Labels: ise
>
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream.
> BinaryObjectBuilderAdditionalSelfTest
> {code:java}
> /** */
> @Test
> public void testArrayFieldSeveralRead() throws Exception {
> try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }
> finally {
> clearBinaryMeta();
> }
> }
> /** Test class with array. */
> public static class TestClsWithArray {
> /** */
> private final Object[] arr;
> /** */
> public TestClsWithArray(TestClass1[] arr) {
> this.arr = arr;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16062) Support binary HANLDEs: Unable read object array twice.
[
https://issues.apache.org/jira/browse/IGNITE-16062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16062:
-
Assignee: Vladimir Ermakov
> Support binary HANLDEs: Unable read object array twice.
> ---
>
> Key: IGNITE-16062
> URL: https://issues.apache.org/jira/browse/IGNITE-16062
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
>
> "Looks like this commit introduce a blocker.
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream."
>
> Reproducer:
> {code:java}
> /** */
> @Test
> public void testArrayFieldSeveralRead() throws Exception {
> try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }
> finally {
> clearBinaryMeta();
> }
> }
> /** Test class with array. */
> public static class TestClsWithArray {
> /** */
> private final Object[] arr;
> /** */
> public TestClsWithArray(TestClass1[] arr) {
> this.arr = arr;
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16062) Support binary HANLDEs: Unable read object array twice.
[
https://issues.apache.org/jira/browse/IGNITE-16062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-16062:
--
Description:
"Looks like this commit introduce a blocker.
Second read of array field fail and read some garbage.
This happen because when object read with handle stream position don't move to
the end of already deserialized object.
So second array element is just random bytes from the middle of the stream."
Reproducer:
{code:java}
/** */
@Test
public void testArrayFieldSeveralRead() throws Exception {
try (Ignite ignite = startGrid(1)) {
TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
TestClass1()};
BinaryObject arrObj = ignite.binary().toBinary(new
TestClsWithArray(expArr));
for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
arrObj =
ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
expArr).build();
for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
}
finally {
clearBinaryMeta();
}
}
/** Test class with array. */
public static class TestClsWithArray {
/** */
private final Object[] arr;
/** */
public TestClsWithArray(TestClass1[] arr) {
this.arr = arr;
}
} {code}
was:
"Looks like this commit introduce a blocker.
Second read of array field fail and read some garbage.
This happen because when object read with handle stream position don't move to
the end of already deserialized object.
So second array element is just random bytes from the middle of the stream."
Reproducer:
/** */@Testpublic void testArrayFieldSeveralRead() throws Exception
{try (Ignite ignite = startGrid(1)) {
TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
TestClass1()};
BinaryObject arrObj = ignite.binary().toBinary(new
TestClsWithArray(expArr));for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
arrObj =
ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
expArr).build();for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
}finally \{
clearBinaryMeta();
}
}/** Test class with array. */public static class TestClsWithArray {
/** */private final Object[] arr;/** */public
TestClsWithArray(TestClass1[] arr) {this.arr = arr;
}
}
> Support binary HANLDEs: Unable read object array twice.
> ---
>
> Key: IGNITE-16062
> URL: https://issues.apache.org/jira/browse/IGNITE-16062
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Priority: Major
>
> "Looks like this commit introduce a blocker.
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream."
>
> Reproducer:
> {code:java}
> /** */
> @Test
> public void testArrayFieldSeveralRead() throws Exception {
> try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }
> finally {
> clearBinaryMeta();
> }
> }
> /** Test class with array. */
> public static class TestClsWithArray {
> /** */
> private final Object[] arr;
> /** */
> public TestClsWithArray(TestClass1[] arr) {
> this.arr = arr;
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16062) Support binary HANLDEs: Unable read object array twice.
[
https://issues.apache.org/jira/browse/IGNITE-16062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-16062:
--
Description:
"Looks like this commit introduce a blocker.
Second read of array field fail and read some garbage.
This happen because when object read with handle stream position don't move to
the end of already deserialized object.
So second array element is just random bytes from the middle of the stream."
Reproducer:
/** */@Testpublic void testArrayFieldSeveralRead() throws Exception
{try (Ignite ignite = startGrid(1)) {
TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
TestClass1()};
BinaryObject arrObj = ignite.binary().toBinary(new
TestClsWithArray(expArr));for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
arrObj =
ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
expArr).build();for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
}finally \{
clearBinaryMeta();
}
}/** Test class with array. */public static class TestClsWithArray {
/** */private final Object[] arr;/** */public
TestClsWithArray(TestClass1[] arr) {this.arr = arr;
}
}
was:
"Looks like this commit introduce a blocker.
Second read of array field fail and read some garbage.
This happen because when object read with handle stream position don't move to
the end of already deserialized object.
So second array element is just random bytes from the middle of the stream."
Reproducer:
/** */@Testpublic void testArrayFieldSeveralRead() throws Exception
{try (Ignite ignite = startGrid(1)) {
TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
TestClass1()};
BinaryObject arrObj = ignite.binary().toBinary(new
TestClsWithArray(expArr));for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
arrObj =
ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
expArr).build();for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
}finally \{
clearBinaryMeta();
}
}/** Test class with array. */public static class TestClsWithArray {
/** */private final Object[] arr;/** */public
TestClsWithArray(TestClass1[] arr) {this.arr = arr;
}
}
> Support binary HANLDEs: Unable read object array twice.
> ---
>
> Key: IGNITE-16062
> URL: https://issues.apache.org/jira/browse/IGNITE-16062
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Priority: Major
>
> "Looks like this commit introduce a blocker.
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream."
>
> Reproducer:
> /** */@Testpublic void testArrayFieldSeveralRead() throws
> Exception {try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }finally \{
> clearBinaryMeta();
> }
> }/** Test class with array. */public static class TestClsWithArray {
> /** */private final Object[] arr;/** */public
> TestClsWithArray(TestClass1[] arr) {this.arr = arr;
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16062) Support binary HANLDEs: Unable read object array twice.
[
https://issues.apache.org/jira/browse/IGNITE-16062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-16062:
--
Description:
"Looks like this commit introduce a blocker.
Second read of array field fail and read some garbage.
This happen because when object read with handle stream position don't move to
the end of already deserialized object.
So second array element is just random bytes from the middle of the stream."
Reproducer:
/** */@Testpublic void testArrayFieldSeveralRead() throws Exception
{try (Ignite ignite = startGrid(1)) {
TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
TestClass1()};
BinaryObject arrObj = ignite.binary().toBinary(new
TestClsWithArray(expArr));for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
arrObj =
ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
expArr).build();for (int i = 0; i < 10; i++)
Assert.assertArrayEquals(i + " iteration", expArr,
PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
}finally \{
clearBinaryMeta();
}
}/** Test class with array. */public static class TestClsWithArray {
/** */private final Object[] arr;/** */public
TestClsWithArray(TestClass1[] arr) {this.arr = arr;
}
}
> Support binary HANLDEs: Unable read object array twice.
> ---
>
> Key: IGNITE-16062
> URL: https://issues.apache.org/jira/browse/IGNITE-16062
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Ermakov
>Priority: Major
>
> "Looks like this commit introduce a blocker.
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream."
>
> Reproducer:
>
> /** */@Testpublic void testArrayFieldSeveralRead() throws
> Exception {try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }finally \{
> clearBinaryMeta();
> }
> }/** Test class with array. */public static class TestClsWithArray {
> /** */private final Object[] arr;/** */public
> TestClsWithArray(TestClass1[] arr) {this.arr = arr;
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16062) Support binary HANLDEs: Unable read object array twice.
Vladimir Ermakov created IGNITE-16062: - Summary: Support binary HANLDEs: Unable read object array twice. Key: IGNITE-16062 URL: https://issues.apache.org/jira/browse/IGNITE-16062 Project: Ignite Issue Type: Bug Reporter: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15978) Support binary HANLDEs by BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453978#comment-17453978
]
Vladimir Ermakov commented on IGNITE-15978:
---
Hello [~nizhikov] Thanks for the bug report. I successfully reproduced it and
working on a fix. I will create a separate task for the fix.
> Support binary HANLDEs by BinaryObjectBuilder
> -
>
> Key: IGNITE-15978
> URL: https://issues.apache.org/jira/browse/IGNITE-15978
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have to support binary HANLDEs by BinaryObjectBuilder.
> Now, the binary object is created by marshaling the java object may contain
> filed that is represented by the HANDLE (reference) to the other member of
> the upper object.e.g.
>
> {code:java}
> class MyClass {
>List lst0;
>List lst1;
> }
> MyClass var = new MyClass();
> var.lst0 = ...;
> var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers
> to the lst0 {code}
> But the same layout of the binary object cannot be built by
> BinaryObjectBuilder.e.g.:
> {code:java}
> BinaryObjectBuilder bob = builder("MyClass");
> List lst = ...;
> bob.setField("lst0", lst);
> bob.setField("lst1", lst);
> BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
> collections will be marshaled independently, {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16041) Fix for comparing BinaryObjects when searching for POJO keys in the index tree.
Vladimir Ermakov created IGNITE-16041: - Summary: Fix for comparing BinaryObjects when searching for POJO keys in the index tree. Key: IGNITE-16041 URL: https://issues.apache.org/jira/browse/IGNITE-16041 Project: Ignite Issue Type: Bug Reporter: Vladimir Ermakov Assignee: Vladimir Ermakov Sometimes (pretty rarely) a certain combination of keys in the index with POJO keys produces index corruption. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16028) Node failure with ClassNotFoundException: wrong validation for Object type
[
https://issues.apache.org/jira/browse/IGNITE-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-16028:
--
Description:
After implementing the fix for IGNITE-13553, we have an issue that Object type
can't be used for any other type except the Object one.
The cache object type can be declared as java.lang.Object. For example,
{code:java}
.addQueryField("val_obj", Object.class.getName(), null){code}
But, we can use BinaryObjectBuilder to build BinaryObject and put it as
'val_obj'.
For example,
{code:java}
BinaryObjectBuilder bobInner = grid().binary().builder("inner");
///
bob.setField("val_obj", bobInner.build());{code}
So, we will have an object with 'inner' class name. But a class with that name
never existed.
During type validation (introduced in IGNITE-13553) the binaryObject's typeId
and the java.lang.Object typeId will not match. Then we will try to get the
class of the object by 'inner' class name, and will definitely face with
ClassNotFoundException.
QueryTypeDescriptorImpl#730 line of code.
Please, see BasicIndexTest#testCacheSecondaryCompositeIndex reproducer for more
details.
was:
After implementing the fix for IGNITE-13553, we have an issue that Object type
can't be used for any other type except the Object one.
The cache object type can be declared as java.lang.Object. For example,
{code:java}
.addQueryField("val_obj", Object.class.getName(), null){code}
But, we can use BinaryObjectBuilder to build BinaryObject and put it as
'val_obj'.
For example,
{code:java}
BinaryObjectBuilder bobInner = grid().binary().builder("inner");
///
bob.setField("val_obj", bobInner.build());{code}
So, we will have an object with 'inner' class name. But a class with that name
never existed.
During type validation (introduced in IGNITE-13553) the binaryObject's typeId
and the java.lang.Object typeId will not match. Then we will try to get the
class of the object by 'inner' class name, and will definitely face with
ClassNotFoundException.
Please, see BasicIndexTest#testCacheSecondaryCompositeIndex reproducer for more
details.
> Node failure with ClassNotFoundException: wrong validation for Object type
> --
>
> Key: IGNITE-16028
> URL: https://issues.apache.org/jira/browse/IGNITE-16028
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After implementing the fix for IGNITE-13553, we have an issue that Object
> type can't be used for any other type except the Object one.
>
> The cache object type can be declared as java.lang.Object. For example,
> {code:java}
> .addQueryField("val_obj", Object.class.getName(), null){code}
> But, we can use BinaryObjectBuilder to build BinaryObject and put it as
> 'val_obj'.
> For example,
> {code:java}
> BinaryObjectBuilder bobInner = grid().binary().builder("inner");
> ///
> bob.setField("val_obj", bobInner.build());{code}
> So, we will have an object with 'inner' class name. But a class with that
> name never existed.
> During type validation (introduced in IGNITE-13553) the binaryObject's typeId
> and the java.lang.Object typeId will not match. Then we will try to get the
> class of the object by 'inner' class name, and will definitely face with
> ClassNotFoundException.
> QueryTypeDescriptorImpl#730 line of code.
>
> Please, see BasicIndexTest#testCacheSecondaryCompositeIndex reproducer for
> more details.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16028) Node failure with ClassNotFoundException: wrong validation for Object type
[
https://issues.apache.org/jira/browse/IGNITE-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451843#comment-17451843
]
Vladimir Ermakov commented on IGNITE-16028:
---
[~nizhikov] I added more details to the description, as well as the link to the
reproducer test.
Please let me know if the case is still unclear. I will try to add more details.
> Node failure with ClassNotFoundException: wrong validation for Object type
> --
>
> Key: IGNITE-16028
> URL: https://issues.apache.org/jira/browse/IGNITE-16028
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After implementing the fix for IGNITE-13553, we have an issue that Object
> type can't be used for any other type except the Object one.
>
> The cache object type can be declared as java.lang.Object. For example,
> {code:java}
> .addQueryField("val_obj", Object.class.getName(), null){code}
> But, we can use BinaryObjectBuilder to build BinaryObject and put it as
> 'val_obj'.
> For example,
> {code:java}
> BinaryObjectBuilder bobInner = grid().binary().builder("inner");
> ///
> bob.setField("val_obj", bobInner.build());{code}
> So, we will have an object with 'inner' class name. But a class with that
> name never existed.
> During type validation (introduced in IGNITE-13553) the binaryObject's typeId
> and the java.lang.Object typeId will not match. Then we will try to get the
> class of the object by 'inner' class name, and will definitely face with
> ClassNotFoundException.
>
> Please, see BasicIndexTest#testCacheSecondaryCompositeIndex reproducer for
> more details.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16028) Node failure with ClassNotFoundException: wrong validation for Object type
[
https://issues.apache.org/jira/browse/IGNITE-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-16028:
--
Description:
After implementing the fix for IGNITE-13553, we have an issue that Object type
can't be used for any other type except the Object one.
The cache object type can be declared as java.lang.Object. For example,
{code:java}
.addQueryField("val_obj", Object.class.getName(), null){code}
But, we can use BinaryObjectBuilder to build BinaryObject and put it as
'val_obj'.
For example,
{code:java}
BinaryObjectBuilder bobInner = grid().binary().builder("inner");
///
bob.setField("val_obj", bobInner.build());{code}
So, we will have an object with 'inner' class name. But a class with that name
never existed.
During type validation (introduced in IGNITE-13553) the binaryObject's typeId
and the java.lang.Object typeId will not match. Then we will try to get the
class of the object by 'inner' class name, and will definitely face with
ClassNotFoundException.
Please, see BasicIndexTest#testCacheSecondaryCompositeIndex reproducer for more
details.
was:After implementing the fix for IGNITE-13553, we have an issue that Object
type can't be used for any other type except the Object one.
> Node failure with ClassNotFoundException: wrong validation for Object type
> --
>
> Key: IGNITE-16028
> URL: https://issues.apache.org/jira/browse/IGNITE-16028
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After implementing the fix for IGNITE-13553, we have an issue that Object
> type can't be used for any other type except the Object one.
>
> The cache object type can be declared as java.lang.Object. For example,
> {code:java}
> .addQueryField("val_obj", Object.class.getName(), null){code}
> But, we can use BinaryObjectBuilder to build BinaryObject and put it as
> 'val_obj'.
> For example,
> {code:java}
> BinaryObjectBuilder bobInner = grid().binary().builder("inner");
> ///
> bob.setField("val_obj", bobInner.build());{code}
> So, we will have an object with 'inner' class name. But a class with that
> name never existed.
> During type validation (introduced in IGNITE-13553) the binaryObject's typeId
> and the java.lang.Object typeId will not match. Then we will try to get the
> class of the object by 'inner' class name, and will definitely face with
> ClassNotFoundException.
>
> Please, see BasicIndexTest#testCacheSecondaryCompositeIndex reproducer for
> more details.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16028) Node failure with ClassNotFoundException: wrong validation for Object type
[ https://issues.apache.org/jira/browse/IGNITE-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451749#comment-17451749 ] Vladimir Ermakov commented on IGNITE-16028: --- Hello, [~tledkov-gridgain] [~NIzhikov]. Could you, please, take a look at my changes? > Node failure with ClassNotFoundException: wrong validation for Object type > -- > > Key: IGNITE-16028 > URL: https://issues.apache.org/jira/browse/IGNITE-16028 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > After implementing the fix for IGNITE-13553, we have an issue that Object > type can't be used for any other type except the Object one. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16028) Node failure with ClassNotFoundException: wrong validation for Object type
Vladimir Ermakov created IGNITE-16028: - Summary: Node failure with ClassNotFoundException: wrong validation for Object type Key: IGNITE-16028 URL: https://issues.apache.org/jira/browse/IGNITE-16028 Project: Ignite Issue Type: Bug Components: sql Reporter: Vladimir Ermakov Assignee: Vladimir Ermakov After implementing the fix for IGNITE-13553, we have an issue that Object type can't be used for any other type except the Object one. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15983) Regression when using SELECT (EXISTS (...)) part 2
Vladimir Ermakov created IGNITE-15983:
-
Summary: Regression when using SELECT (EXISTS (...)) part 2
Key: IGNITE-15983
URL: https://issues.apache.org/jira/browse/IGNITE-15983
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Vladimir Ermakov
Assignee: Vladimir Ermakov
In the task https://issues.apache.org/jira/browse/IGNITE-14354 erroneous
queries were not fully corrected.
So, a query like
{code:java}
CREATE TABLE t (i int PRIMARY KEY, j int);
SELECT (EXISTS (SELECT 1 FROM t WHERE t.i = 1)); {code}
now passes, when a query
{code:java}
CREATE TABLE t (i int PRIMARY KEY, j int);
SELECT (EXISTS (SELECT i FROM t WHERE t.i = 1)); {code}
still fails.
The original cause of the error must be fixed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15978) Support binary HANLDEs by BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-15978:
--
Description:
We have to support binary HANLDEs by BinaryObjectBuilder.
Now, the binary object is created by marshaling the java object may contain
filed that is represented by the HANDLE (reference) to the other member of the
upper object.e.g.
{code:java}
class MyClass {
List lst0;
List lst1;
}
MyClass var = new MyClass();
var.lst0 = ...;
var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers to
the lst0 {code}
But the same layout of the binary object cannot be built by
BinaryObjectBuilder.e.g.:
{code:java}
BinaryObjectBuilder bob = builder("MyClass");
List lst = ...;
bob.setField("lst0", lst);
bob.setField("lst1", lst);
BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
collections will be marshaled independently, {code}
was:
We have to support binary HANLDEs by BinaryObjectBuilder.
Now, the binary object is created by marshaling the java object may contain
filed that is represented by the HANDLE (reference) to the other member of the
upper object.e.g.
{{class MyClass \{
List lst0;
List lst1;
}
MyClass var = new MyClass();
var.lst0 = ...;
var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers to
the lst0}}
But the same layout of the binary object cannot be built by
BinaryObjectBuilder.e.g.:
BinaryObjectBuilder bob = builder("MyClass");
List lst = ...;
bob.setField("lst0", lst);
bob.setField("lst1", lst);
BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
collections will be marshaled independently,
.
> Support binary HANLDEs by BinaryObjectBuilder
> -
>
> Key: IGNITE-15978
> URL: https://issues.apache.org/jira/browse/IGNITE-15978
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
>
> We have to support binary HANLDEs by BinaryObjectBuilder.
> Now, the binary object is created by marshaling the java object may contain
> filed that is represented by the HANDLE (reference) to the other member of
> the upper object.e.g.
>
> {code:java}
> class MyClass {
>List lst0;
>List lst1;
> }
> MyClass var = new MyClass();
> var.lst0 = ...;
> var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers
> to the lst0 {code}
> But the same layout of the binary object cannot be built by
> BinaryObjectBuilder.e.g.:
> {code:java}
> BinaryObjectBuilder bob = builder("MyClass");
> List lst = ...;
> bob.setField("lst0", lst);
> bob.setField("lst1", lst);
> BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
> collections will be marshaled independently, {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15978) Support binary HANLDEs by BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-15978:
--
Description:
We have to support binary HANLDEs by BinaryObjectBuilder.
Now, the binary object is created by marshaling the java object may contain
filed that is represented by the HANDLE (reference) to the other member of the
upper object.e.g.
{{class MyClass \{
List lst0;
List lst1;
}
MyClass var = new MyClass();
var.lst0 = ...;
var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers to
the lst0}}
But the same layout of the binary object cannot be built by
BinaryObjectBuilder.e.g.:
BinaryObjectBuilder bob = builder("MyClass");
List lst = ...;
bob.setField("lst0", lst);
bob.setField("lst1", lst);
BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
collections will be marshaled independently,
.
was:
We have to support binary HANLDEs by BinaryObjectBuilder.
Now, the binary object is created by marshaling the java object may contain
filed that is represented by the HANDLE (reference) to the other member of the
upper object.e.g.
class MyClass {
List lst0;
List lst1;
}
MyClass var = new MyClass();
var.lst0 = ...;
var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers to
the lst0
But the same layout of the binary object cannot be built by
BinaryObjectBuilder.e.g.:
BinaryObjectBuilder bob = builder("MyClass");
List lst = ...;
bob.setField("lst0", lst);
bob.setField("lst1", lst);
BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
collections will be marshaled independently,
.
> Support binary HANLDEs by BinaryObjectBuilder
> -
>
> Key: IGNITE-15978
> URL: https://issues.apache.org/jira/browse/IGNITE-15978
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
>
> We have to support binary HANLDEs by BinaryObjectBuilder.
> Now, the binary object is created by marshaling the java object may contain
> filed that is represented by the HANDLE (reference) to the other member of
> the upper object.e.g.
>
> {{class MyClass \{
>List lst0;
>List lst1;
> }
> MyClass var = new MyClass();
> var.lst0 = ...;
> var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers
> to the lst0}}
>
> But the same layout of the binary object cannot be built by
> BinaryObjectBuilder.e.g.:
> BinaryObjectBuilder bob = builder("MyClass");
> List lst = ...;
> bob.setField("lst0", lst);
> bob.setField("lst1", lst);
> BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
> collections will be marshaled independently,
> .
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-15978) Support binary HANLDEs by BinaryObjectBuilder
Vladimir Ermakov created IGNITE-15978:
-
Summary: Support binary HANLDEs by BinaryObjectBuilder
Key: IGNITE-15978
URL: https://issues.apache.org/jira/browse/IGNITE-15978
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Vladimir Ermakov
Assignee: Vladimir Ermakov
We have to support binary HANLDEs by BinaryObjectBuilder.
Now, the binary object is created by marshaling the java object may contain
filed that is represented by the HANDLE (reference) to the other member of the
upper object.e.g.
class MyClass {
List lst0;
List lst1;
}
MyClass var = new MyClass();
var.lst0 = ...;
var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers to
the lst0
But the same layout of the binary object cannot be built by
BinaryObjectBuilder.e.g.:
BinaryObjectBuilder bob = builder("MyClass");
List lst = ...;
bob.setField("lst0", lst);
bob.setField("lst1", lst);
BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
collections will be marshaled independently,
.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-14354) Regression when using SELECT (EXISTS (...))
[
https://issues.apache.org/jira/browse/IGNITE-14354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-14354:
-
Assignee: Vladimir Ermakov
> Regression when using SELECT (EXISTS (...))
> ---
>
> Key: IGNITE-14354
> URL: https://issues.apache.org/jira/browse/IGNITE-14354
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Lukas Eder
>Assignee: Vladimir Ermakov
>Priority: Major
>
> This worked as expected in 2.9.1:
>
> {code:java}
> CREATE TABLE t (i int PRIMARY KEY, j int);
> SELECT (EXISTS (SELECT 1 FROM t WHERE t.i = 1));
> {code}
> In version 2.10, I'm getting:
> {code:java}
> SQL Error [1001] [42000]: Failed to parse query. Column "EXISTS1" not found;
> SQL statement:
> SELECT
> (EXISTS1)
> FROM SYSTEM_RANGE(1, 1) __Z0
> LEFT OUTER JOIN PUBLIC.T __Z1
> ON __Z1.I = 1 [42122-197]{code}
> The workaround is to project an asterisk:
> {code:java}
> SELECT (EXISTS (SELECT * FROM t WHERE t.i = 1));{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15700) Rename 'Table#tableName' method to 'name'
[
https://issues.apache.org/jira/browse/IGNITE-15700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-15700:
-
Assignee: Vladimir Ermakov
> Rename 'Table#tableName' method to 'name'
> -
>
> Key: IGNITE-15700
> URL: https://issues.apache.org/jira/browse/IGNITE-15700
> Project: Ignite
> Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: ignite-3
>
> The {{table}} prefix seems redundant here.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15846) Provide Interface for external table
[ https://issues.apache.org/jira/browse/IGNITE-15846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15846: - Assignee: Vladimir Ermakov > Provide Interface for external table > > > Key: IGNITE-15846 > URL: https://issues.apache.org/jira/browse/IGNITE-15846 > Project: Ignite > Issue Type: Sub-task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Vladimir Ermakov >Priority: Major > Labels: calcite, calcite3-required, ignite-3 > > In order to provide interfaces for SQL Extension API need to expose an > interface for external table (IgniteExternalTable). It could be reduced > IgniteTable. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15443) Add Map with primitive keys implementations.
[ https://issues.apache.org/jira/browse/IGNITE-15443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17438054#comment-17438054 ] Vladimir Ermakov commented on IGNITE-15443: --- Based on the article ([http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/)] and the tests attached to it ([https://github.com/mikvor/hashmapTest]), I made a comparison of different map implementations(including IntMap from Ignite 2, FastUtils, Netty, Trove, JDK and OpenHFT). The fastest in the tests were Ignite 2 and FastUtils implementations. After reviewing the code, it became clear that the implementation of the maps is quite similar. However, in FastUtils library some parts of the code are more optimal due to less creation of objects. Given that FastUtils library may contain other useful data structures, it was decided to add it as dependency to the project using the maven-shading plugin. The dependency will be added in the IGNITE-15462 task. > Add Map with primitive keys implementations. > > > Key: IGNITE-15443 > URL: https://issues.apache.org/jira/browse/IGNITE-15443 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3, newbie, perfomance > > There are a number of places where Map and Map Object> are used. > Let's add an optimized Map with a primitive key (IntMap, IntIntMap) to the > ignite-core module. > Let's benchmark next candidates and choose one > * IntMap from Ignite 2 with robinhood hashing. > * FastUtils > * Netty > * OpenHFT -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15870) Calcite. Replace usages of Lists and Sets of int to IntList\IntSet where possible
[
https://issues.apache.org/jira/browse/IGNITE-15870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov updated IGNITE-15870:
--
Description: Currently there is a number of List\Set
usages in {{ignite-calcite}} module. Better to replace them with more optimal
fastUtils List\Set for int primitives.
> Calcite. Replace usages of Lists and Sets of int to IntList\IntSet where
> possible
> -
>
> Key: IGNITE-15870
> URL: https://issues.apache.org/jira/browse/IGNITE-15870
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vladimir Ermakov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3,
> tech-debt
>
> Currently there is a number of List\Set usages in
> {{ignite-calcite}} module. Better to replace them with more optimal fastUtils
> List\Set for int primitives.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15870) Calcite. Replace usages of Lists and Sets of int to IntList\IntSet where possible
Vladimir Ermakov created IGNITE-15870: - Summary: Calcite. Replace usages of Lists and Sets of int to IntList\IntSet where possible Key: IGNITE-15870 URL: https://issues.apache.org/jira/browse/IGNITE-15870 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-alpha3 Reporter: Vladimir Ermakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15462) Calcite. Replace usages of map of int to IntMap where possible
[
https://issues.apache.org/jira/browse/IGNITE-15462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-15462:
-
Assignee: Vladimir Ermakov
> Calcite. Replace usages of map of int to IntMap where possible
> --
>
> Key: IGNITE-15462
> URL: https://issues.apache.org/jira/browse/IGNITE-15462
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3,
> tech-debt
>
> Currently there is a number of {{Map}} usages in
> {{ignite-calcite}} module. Better to replace them with more optimal
> {{org.apache.ignite.internal.util.collection.IntMap}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15443) Add Map with primitive keys implementations.
[ https://issues.apache.org/jira/browse/IGNITE-15443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15443: - Assignee: Vladimir Ermakov (was: Anton Kholodkov) > Add Map with primitive keys implementations. > > > Key: IGNITE-15443 > URL: https://issues.apache.org/jira/browse/IGNITE-15443 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3, newbie, perfomance > > There are a number of places where Map and Map Object> are used. > Let's add an optimized Map with a primitive key (IntMap, IntIntMap) to the > ignite-core module. > Let's benchmark next candidates and choose one > * IntMap from Ignite 2 with robinhood hashing. > * FastUtils > * Netty > * OpenHFT -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15648) JDBC driver for 3.0: Add integration tests that depend on the data layer.
Vladimir Ermakov created IGNITE-15648: - Summary: JDBC driver for 3.0: Add integration tests that depend on the data layer. Key: IGNITE-15648 URL: https://issues.apache.org/jira/browse/IGNITE-15648 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov Assignee: Vladimir Ermakov Subj -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14358) Regression when referencing aliased constant from derived table
[
https://issues.apache.org/jira/browse/IGNITE-14358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-14358:
-
Assignee: Vladimir Ermakov
> Regression when referencing aliased constant from derived table
> ---
>
> Key: IGNITE-14358
> URL: https://issues.apache.org/jira/browse/IGNITE-14358
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Lukas Eder
>Assignee: Vladimir Ermakov
>Priority: Major
>
> This used to work in 2.9.1 but no longer does in 2.10.0:
>
> {code:java}
> CREATE TABLE t (i int PRIMARY KEY, j int);
> INSERT INTO t VALUES (1, 1);
> SELECT u.x
> FROM (
> SELECT 1 AS x
> FROM t
> ) u;
> {code}
>
> The error I'm getting is:
> {noformat}
> SQL Error [1001] [42000]: Failed to parse query. Column "U__Z0.X" not found;
> SQL statement:
> SELECT
> U__Z0.X
> FROM PUBLIC.T U__Z0 [42122-197]{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14356) Regression when using derived table in LEFT JOIN
[
https://issues.apache.org/jira/browse/IGNITE-14356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-14356:
-
Assignee: Vladimir Ermakov
> Regression when using derived table in LEFT JOIN
>
>
> Key: IGNITE-14356
> URL: https://issues.apache.org/jira/browse/IGNITE-14356
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Lukas Eder
>Assignee: Vladimir Ermakov
>Priority: Major
>
> This used to work in 2.9.1 and no longer does in 2.10.0:
>
> {code:java}
> CREATE TABLE t (i int PRIMARY KEY, j int);
> INSERT INTO t VALUES (1, 1);
> SELECT *
> FROM t AS t1
> LEFT JOIN (SELECT * FROM t WHERE false) AS t2
> ON t1.i = t2.i
> {code}
>
> It should result in 1 row as the LEFT JOIN should have no effect, but the
> result set is empty as if t2 were inner joined.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15545) [Ignite 3] Create SQL example(s)
[ https://issues.apache.org/jira/browse/IGNITE-15545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15545: - Assignee: Vladimir Ermakov > [Ignite 3] Create SQL example(s) > > > Key: IGNITE-15545 > URL: https://issues.apache.org/jira/browse/IGNITE-15545 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Valentin Kulichenko >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Need to add an example (or a set of examples) for the SQL functionality added > to alpha 3. Since there is no native API for SQL yet, let's use JDBC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15508) JDBC driver for 3.0: Support JDBC driver loading by ServiceLoader
[ https://issues.apache.org/jira/browse/IGNITE-15508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15508: - Assignee: Vladimir Ermakov > JDBC driver for 3.0: Support JDBC driver loading by ServiceLoader > - > > Key: IGNITE-15508 > URL: https://issues.apache.org/jira/browse/IGNITE-15508 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > > Support JDBC driver loading by ServiceLoader. > All is needed is to add classname to META_INF/services/java.sql.Driver file. > It is also necessary to check whether the driver needs to be registered > additionally via a static block. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15362) Fix SchemaChange integration tests.
[ https://issues.apache.org/jira/browse/IGNITE-15362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15362: - Assignee: Vladimir Ermakov (was: Andrey Mashenkov) > Fix SchemaChange integration tests. > --- > > Key: IGNITE-15362 > URL: https://issues.apache.org/jira/browse/IGNITE-15362 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Mashenkov >Assignee: Vladimir Ermakov >Priority: Blocker > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > > We have a number of tests muted with the ticket (IGNITE-14581) that is > already done: > SchemaChangeKVViewTest > SchemaChangeTableViewTest > LiveSchemaChangeTableTest > LiveSchemaChangeKVViewTest > # These tests hang forever and must be fixed. > # Integration tests names must start from "IT" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-15314) JDBC driver for 3.0: ClientInboundMessageHandler refactoring.
[ https://issues.apache.org/jira/browse/IGNITE-15314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov resolved IGNITE-15314. --- Resolution: Invalid > JDBC driver for 3.0: ClientInboundMessageHandler refactoring. > - > > Key: IGNITE-15314 > URL: https://issues.apache.org/jira/browse/IGNITE-15314 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql >Reporter: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > ClientInboundMessageHandler should use Ignite interface sql api appears there. > Protected constructor should be removed from IgniteImpl as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15529) JDBC driver for 3.0: list all supported sql functions
Vladimir Ermakov created IGNITE-15529: - Summary: JDBC driver for 3.0: list all supported sql functions Key: IGNITE-15529 URL: https://issues.apache.org/jira/browse/IGNITE-15529 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov DatabaseMetadata#getFunctions method should return all sql functions supported by Calcite. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15527) Check ANSI92 entry level SQL support.
Vladimir Ermakov created IGNITE-15527: - Summary: Check ANSI92 entry level SQL support. Key: IGNITE-15527 URL: https://issues.apache.org/jira/browse/IGNITE-15527 Project: Ignite Issue Type: Improvement Components: sql Reporter: Vladimir Ermakov Since we are claiming full support for ANSI92 sql, compatibility tests for at least ANSI92 entry level should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15525) JDBC driver for 3.0: Add view filter support
Vladimir Ermakov created IGNITE-15525: - Summary: JDBC driver for 3.0: Add view filter support Key: IGNITE-15525 URL: https://issues.apache.org/jira/browse/IGNITE-15525 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov Filter by table type must be added after 'view' type will appear. See JdbcMetadataCatalog. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15508) JDBC driver for 3.0: Support JDBC driver loading by ServiceLoader
Vladimir Ermakov created IGNITE-15508: - Summary: JDBC driver for 3.0: Support JDBC driver loading by ServiceLoader Key: IGNITE-15508 URL: https://issues.apache.org/jira/browse/IGNITE-15508 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov Support JDBC driver loading by ServiceLoader. All is needed is to add classname to META_INF/services/java.sql.Driver file. It is also necessary to check whether the driver needs to be registered additionally via a static block. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15507) JDBC driver for 3.0: Implements Time API support
Vladimir Ermakov created IGNITE-15507: - Summary: JDBC driver for 3.0: Implements Time API support Key: IGNITE-15507 URL: https://issues.apache.org/jira/browse/IGNITE-15507 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov Fix For: 3.0.0-alpha3 Calcite currently works with old java Date API in queries only. After integration with new java Time API will be implemented, it is necessary to support it in JDBC driver. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14679) Implement schema history serialization.
[ https://issues.apache.org/jira/browse/IGNITE-14679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-14679: - Assignee: Vladimir Ermakov > Implement schema history serialization. > --- > > Key: IGNITE-14679 > URL: https://issues.apache.org/jira/browse/IGNITE-14679 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Vladimir Ermakov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 120h > Remaining Estimate: 120h > > As for now, we store history in distributed metastorage as Serializable > objects just for simplicity. > Let's serialize these objects for better portability and for compaction > purpose. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15428) JDBC driver for 3.0: Implements SSL connection
Vladimir Ermakov created IGNITE-15428: - Summary: JDBC driver for 3.0: Implements SSL connection Key: IGNITE-15428 URL: https://issues.apache.org/jira/browse/IGNITE-15428 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov Fix For: 3.0.0-alpha3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15187) JDBC driver for 3.0: Implements ResultSetMetadata
[ https://issues.apache.org/jira/browse/IGNITE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15187: - Assignee: Vladimir Ermakov > JDBC driver for 3.0: Implements ResultSetMetadata > - > > Key: IGNITE-15187 > URL: https://issues.apache.org/jira/browse/IGNITE-15187 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Taras Ledkov >Assignee: Vladimir Ermakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Implements ResultSetMetadata. > Extends > [IEP-76|https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0] > with new commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15188) JDBC driver for 3.0: Implements DatabaseMetadata
[
https://issues.apache.org/jira/browse/IGNITE-15188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-15188:
-
Assignee: Vladimir Ermakov
> JDBC driver for 3.0: Implements DatabaseMetadata
>
>
> Key: IGNITE-15188
> URL: https://issues.apache.org/jira/browse/IGNITE-15188
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Reporter: Taras Ledkov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: ignite-3
>
> Implements DatabaseMetadata.
> Extends
> [IEP-76|https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0]
> with new commands.
> Take a look at the common approach for the metadata / view at the Ignite 2.x:
> {{SystemViewRowAttributeWalker}}, {{SchemaManager}}. Looks like we should use
> best practice from Ignite 2.x.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15314) JDBC driver for 3.0: ClientInboundMessageHandler refactoring.
Vladimir Ermakov created IGNITE-15314: - Summary: JDBC driver for 3.0: ClientInboundMessageHandler refactoring. Key: IGNITE-15314 URL: https://issues.apache.org/jira/browse/IGNITE-15314 Project: Ignite Issue Type: Improvement Components: jdbc, sql Reporter: Vladimir Ermakov Fix For: 3.0.0-alpha3 ClientInboundMessageHandler should use Ignite interface sql api appears there. Protected constructor should be removed from IgniteImpl as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15186) JDBC driver for 3.0: Implements Statements
[ https://issues.apache.org/jira/browse/IGNITE-15186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-15186: - Assignee: Vladimir Ermakov > JDBC driver for 3.0: Implements Statements > -- > > Key: IGNITE-15186 > URL: https://issues.apache.org/jira/browse/IGNITE-15186 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Taras Ledkov >Assignee: Vladimir Ermakov >Priority: Major > > Implements Statement, PreparedStatement and ResultSet. > Extends > [IEP-76|https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0] > with new commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15185) JDBC driver for 3.0: Implements Driver & Connection
[
https://issues.apache.org/jira/browse/IGNITE-15185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-15185:
-
Assignee: Vladimir Ermakov
> JDBC driver for 3.0: Implements Driver & Connection
> ---
>
> Key: IGNITE-15185
> URL: https://issues.apache.org/jira/browse/IGNITE-15185
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Reporter: Taras Ledkov
>Assignee: Vladimir Ermakov
>Priority: Major
>
> Implements JDBC driver & Connection according with
> [IEP-76|https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0].
> See more at Ignite 2.x:
> - driver implementation: {{IgniteJdbcThinDriver}}
> - connection properties: {{ConnectionPropertiesImpl}}
> Create ticket to documentation JDBC connection string & connection properties
> (for now it will only be network properties).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13668) Implement Number(n) and Decimal native types
[
https://issues.apache.org/jira/browse/IGNITE-13668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-13668:
-
Assignee: Vladimir Ermakov
> Implement Number(n) and Decimal native types
>
>
> Key: IGNITE-13668
> URL: https://issues.apache.org/jira/browse/IGNITE-13668
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: iep-54, ignite-3
> Fix For: 3.0.0-alpha3
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Let's extend native support for Numeric types.
> * Number( n ) is an {{n}}-bytes two-complement integer signed value encoded
> in the varlong style
> (so that Number(4) can be mapped to integer and Number(8) can be mapped to
> long during (de)serialization).
> * Larger numbers can be represented as {{BigInteger}}.
> * The Number( n ) is a varlen type, so it will take two additional bytes in
> the varlen table, so types smaller than Number(4) are better represented by
> {{byte}} and {{short}} and {{int}} types as their fixlen encoding takes
> exactly 1, 2, 4 bytes respectively.
> * Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14861) Live-schema. Detect new row version.
[ https://issues.apache.org/jira/browse/IGNITE-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-14861: - Assignee: Vladimir Ermakov > Live-schema. Detect new row version. > > > Key: IGNITE-14861 > URL: https://issues.apache.org/jira/browse/IGNITE-14861 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Vladimir Ermakov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > > Let's detect schema change and trigger registering a new schema version. > Valid changes are: > * adding a new column > * changing column type to a wider one. (e.g. int -> long) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14636) Calcite engine. Support for LISTAGG (aka GROUP_CONCAT, STRING_AGG) aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-14636:
-
Assignee: Vladimir Ermakov
> Calcite engine. Support for LISTAGG (aka GROUP_CONCAT, STRING_AGG) aggregate
> function
> -
>
> Key: IGNITE-14636
> URL: https://issues.apache.org/jira/browse/IGNITE-14636
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Tests:
> {{aggregate/aggregates/test_aggregate_types.test}}
> {{aggregate/aggregates/test_aggregate_types_scalar.test}}
> {{aggregate/aggregates/test_distinct_string_agg.test_ignore}}
> {{aggregate/aggregates/test_string_agg.test_ignore}}
> {{aggregate/aggregates/test_string_agg_big.test_ignore}}
> {{aggregate/aggregates/test_string_agg_many_groups.test_slow_ignored}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14589) Calcite engine. Numerous problem with type Decimal
[
https://issues.apache.org/jira/browse/IGNITE-14589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-14589:
-
Assignee: Vladimir Ermakov
> Calcite engine. Numerous problem with type Decimal
> --
>
> Key: IGNITE-14589
> URL: https://issues.apache.org/jira/browse/IGNITE-14589
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> There are numerous problem with a decimal types:
> * very big numbers printed in scientific notation
> * leading and trailing zeros are truncated when converting to string
> * casting to precise scale is not working( {{select cast('0.01' as
> decimal(10, 1)) * 10}} returns 0.1 instead of 0)
> Affected tests:
> {{src/test/sql/types/decimal}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14120) select count * returns multiple rows
[ https://issues.apache.org/jira/browse/IGNITE-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361538#comment-17361538 ] Vladimir Ermakov commented on IGNITE-14120: --- My changes are not related to a possible blocker. As I see in teamcity, RDD tests will fail almost universally with exit code 130. The problem is mentioned in devlist. > select count * returns multiple rows > > > Key: IGNITE-14120 > URL: https://issues.apache.org/jira/browse/IGNITE-14120 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8.1 >Reporter: Isaac Zhu >Assignee: Vladimir Ermakov >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > I have a partitioned table which has 1 backup, the *queryParallelism* is set > to 4. > The table primary key is column "ID", > If I do this query: > select count( * ) from my_table where ID = 1000; > It will return 4 rows: > 1 > 0 > 0 > 0 > > If I query by other not primary-key columns of this table, the result is > good, like: > select count( *) from my_table where name = 'abcd' > result is: > 0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
