[jira] [Updated] (IGNITE-16104) [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8
[ https://issues.apache.org/jira/browse/IGNITE-16104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16104: --- Labels: IEP-56 ise (was: IEP-56) > [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to > LATEST_2_8 > --- > > Key: IGNITE-16104 > URL: https://issues.apache.org/jira/browse/IGNITE-16104 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Trivial > Labels: IEP-56, ise > > PersistenceUpgradeTest.upgrade_test > change OLDEST version to LATEST_2_8 > this test is failed if we run this test with SSL use globals parameters > in version 2.7.6 the control.sh utils used other arguments for SSL -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16104) [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8
[ https://issues.apache.org/jira/browse/IGNITE-16104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16104: --- Labels: IEP-56 (was: ) > [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to > LATEST_2_8 > --- > > Key: IGNITE-16104 > URL: https://issues.apache.org/jira/browse/IGNITE-16104 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Trivial > Labels: IEP-56 > > PersistenceUpgradeTest.upgrade_test > change OLDEST version to LATEST_2_8 > this test is failed if we run this test with SSL use globals parameters > in version 2.7.6 the control.sh utils used other arguments for SSL -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16104) [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8
[ https://issues.apache.org/jira/browse/IGNITE-16104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16104: --- Ignite Flags: (was: Docs Required,Release Notes Required) > [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to > LATEST_2_8 > --- > > Key: IGNITE-16104 > URL: https://issues.apache.org/jira/browse/IGNITE-16104 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Trivial > > PersistenceUpgradeTest.upgrade_test > change OLDEST version to LATEST_2_8 > this test is failed if we run this test with SSL use globals parameters > in version 2.7.6 the control.sh utils used other arguments for SSL -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16104) [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8
[ https://issues.apache.org/jira/browse/IGNITE-16104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16104: --- Labels: iep (was: ) > [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to > LATEST_2_8 > --- > > Key: IGNITE-16104 > URL: https://issues.apache.org/jira/browse/IGNITE-16104 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Trivial > Labels: iep > > PersistenceUpgradeTest.upgrade_test > change OLDEST version to LATEST_2_8 > this test is failed if we run this test with SSL use globals parameters > in version 2.7.6 the control.sh utils used other arguments for SSL -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16104) [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8
[ https://issues.apache.org/jira/browse/IGNITE-16104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16104: --- Labels: (was: iep) > [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to > LATEST_2_8 > --- > > Key: IGNITE-16104 > URL: https://issues.apache.org/jira/browse/IGNITE-16104 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Trivial > > PersistenceUpgradeTest.upgrade_test > change OLDEST version to LATEST_2_8 > this test is failed if we run this test with SSL use globals parameters > in version 2.7.6 the control.sh utils used other arguments for SSL -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16104) [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8
Sergei Ryzhov created IGNITE-16104: -- Summary: [ducktests] PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8 Key: IGNITE-16104 URL: https://issues.apache.org/jira/browse/IGNITE-16104 Project: Ignite Issue Type: Test Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov PersistenceUpgradeTest.upgrade_test change OLDEST version to LATEST_2_8 this test is failed if we run this test with SSL use globals parameters in version 2.7.6 the control.sh utils used other arguments for SSL -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15996) Node fails with "Node with the same ID was found" while connecting to the cluster in Docker container if previous container was stopped
[
https://issues.apache.org/jira/browse/IGNITE-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457295#comment-17457295
]
Guilherme Momesso edited comment on IGNITE-15996 at 12/10/21, 5:40 PM:
---
I'm facing the same issue while running on a Kubernetes cluster managed by
Rancher.
Like [~krybakova] pointed, the error starts when the 3rd pod is launched. Then
after a while all of the three pods keeps restarting with "Node with the same
ID was found in node IDs history" error. After some time one pod stays running
stable and the other two keep restarting.
I can only use 2 nodes again if I finish all the nodes and start again.
I'm using Apache Ignite 2.11.0 with TcpDiscoveryKubernetesIpFinder as IP
finder. The nodes are AWS EC2 Linux instances. I've followed the
Installation->Kubernetes steps of the documentation and the only difference I
remember now is that I configure the K8s Service type as "ClusterIP" instead of
"LoadBalancer".
Unfortunately, I can't use the pointed workaround.
was (Author: JIRAUSER281553):
I'm facing the same issue while running on a Kubernetes cluster managed by
Rancher.
Like [~krybakova] pointed, the error starts when the 3rd pod is launched. Then
after a while all of the three pods keeps restarting with "Node with the same
ID was found in node IDs history" error. After some time one pod stays running
stable and the other two keep restarting.
I can only use 2 nodes again if I finish all the nodes and start again.
I'm using TcpDiscoveryKubernetesIpFinder as IP finder. The nodes are AWS EC2
Linux instances. I've followed the Installation->Kubernetes steps of the
documentation and the only difference I remember now is that I configure the
K8s Service type as "ClusterIP" instead of "LoadBalancer".
Unfortunately, I can't use the pointed workaround.
> Node fails with "Node with the same ID was found" while connecting to the
> cluster in Docker container if previous container was stopped
> ---
>
> Key: IGNITE-15996
> URL: https://issues.apache.org/jira/browse/IGNITE-15996
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Windows 10, Docker+WSL2
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: ignite-47b5227b.0.log, ignite-c072978e.0.log,
> ignite-c62bc58e.0.log
>
>
> Node in Docker container fails to connect to existing cluster if previously
> connected node (container) was stopped:
> {noformat}
> [11:27:38,272][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1990)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1331)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@21f9277b],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:281)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1985)
> ... 11 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Node with the same
> ID was found in node IDs history or existing node in topology has the same ID
> (fix configuration and
[jira] [Commented] (IGNITE-15996) Node fails with "Node with the same ID was found" while connecting to the cluster in Docker container if previous container was stopped
[
https://issues.apache.org/jira/browse/IGNITE-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457295#comment-17457295
]
Guilherme Momesso commented on IGNITE-15996:
I'm facing the same issue while running on a Kubernetes cluster managed by
Rancher.
Like [~krybakova] pointed, the error starts when the 3rd pod is launched. Then
after a while all of the three pods keeps restarting with "Node with the same
ID was found in node IDs history" error. After some time one pod stays running
stable and the other two keep restarting.
I can only use 2 nodes again if I finish all the nodes and start again.
I'm using TcpDiscoveryKubernetesIpFinder as IP finder. The nodes are AWS EC2
Linux instances. I've followed the Installation->Kubernetes steps of the
documentation and the only difference I remember now is that I configure the
K8s Service type as "ClusterIP" instead of "LoadBalancer".
Unfortunately, I can't use the pointed workaround.
> Node fails with "Node with the same ID was found" while connecting to the
> cluster in Docker container if previous container was stopped
> ---
>
> Key: IGNITE-15996
> URL: https://issues.apache.org/jira/browse/IGNITE-15996
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Windows 10, Docker+WSL2
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: ignite-47b5227b.0.log, ignite-c072978e.0.log,
> ignite-c62bc58e.0.log
>
>
> Node in Docker container fails to connect to existing cluster if previously
> connected node (container) was stopped:
> {noformat}
> [11:27:38,272][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1990)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1331)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@21f9277b],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:281)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1985)
> ... 11 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Node with the same
> ID was found in node IDs history or existing node in topology has the same ID
> (fix configuration and restart local node) [localNode=TcpDiscoveryNode
> [id=c62bc58e-102a-4928-8e54-ac8a56bf4d44,
> consistentId=127.0.0.1,172.17.0.4:47500, addrs=ArrayList [127.0.0.1,
> 172.17.0.4], sockAddrs=HashSet [402b337a50dd/172.17.0.4:47500,
> /127.0.0.1:47500], discPort=47500, order=0, intOrder=3,
> lastExchangeTime=1637839658247, loc=true, ver=2.11.0#20210911-sha1:8f3f07d3,
> isClient=false], existingNode=c62bc58e-102a-4928-8e54-ac8a56bf4d44]
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.duplicateIdError(TcpDiscoverySpi.java:2083)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1201)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:473)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2207)
> at
>
[jira] [Created] (IGNITE-16103) Failed to create index for table "table" with some options
Maksim Timonin created IGNITE-16103: --- Summary: Failed to create index for table "table" with some options Key: IGNITE-16103 URL: https://issues.apache.org/jira/browse/IGNITE-16103 Project: Ignite Issue Type: Bug Components: sql Reporter: Maksim Timonin 1. How to reproduce - all options CACHE_NAME, VALUE_TYPE, INLINE_SIZE should be in the queries to reproduce failure: ``` create table table(id int PRIMARY KEY, fld1 int, fld2 int) with "CACHE_NAME=TEST_CACHE_NAME,VALUE_TYPE=TEST_VALUE_TYPE"; create index idx_0 on table(fld1, fld2) INLINE_SIZE 0; ``` Creation of index fails with exception: Syntax error in SQL statement "CREATE INDEX IDX_0 ON TABLE(FLD1, FLD2) INLINE_SIZE[*] 0 "; SQL statement: create index IDX_0 on table(fld1, fld2) INLINE_SIZE 0 [42000-197] at 2. How to fix: need to debug why parameters matters, looks like appearance of this options triggers some checks that doesn't run while no options specified. Then this checks should be triggers independently on specified options or should be removed (depends on). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15926) Implement two methods for dropping a table for the table existing and not
[
https://issues.apache.org/jira/browse/IGNITE-15926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457237#comment-17457237
]
Evgeny Stanilovsky commented on IGNITE-15926:
-
I suppose it resolved erroneously, correct exception not thrown. Plz reopen it?
I can call more that once tableManager.dropTable("TBL_NAME") and no exception
thrown, also a can call it with not existing table, and no exception will be
raised.
> Implement two methods for dropping a table for the table existing and not
> -
>
> Key: IGNITE-15926
> URL: https://issues.apache.org/jira/browse/IGNITE-15926
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> ANSI standard requires two methods for dropping table for the two DDL:
> _DROP TABLE [ IF EXISTS ] syntax_
> for the purpose, Table manager should provide two methods with similar
> semantic.
> {code}
> TableManager#dropTable(String) throws TableNotExists
> TableManager#dropTableIfExists(String)
> {code}
> Also we need to support [1] ALTER TABLE [ IF EXISTS ] [ADD|DROP|ALTER] COLUMN
> [1] https://postgrespro.ru/docs/postgrespro/9.6/sql-altertable
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16101) Update Ignite dependency log4j
[ https://issues.apache.org/jira/browse/IGNITE-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16101: --- Security: (was: Private) > Update Ignite dependency log4j > -- > > Key: IGNITE-16101 > URL: https://issues.apache.org/jira/browse/IGNITE-16101 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Blocker > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency: log4j to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16101) Update Ignite dependency log4j
[ https://issues.apache.org/jira/browse/IGNITE-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16101: --- Priority: Critical (was: Major) > Update Ignite dependency log4j > -- > > Key: IGNITE-16101 > URL: https://issues.apache.org/jira/browse/IGNITE-16101 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Critical > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency: log4j to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16101) Update Ignite dependency log4j
[ https://issues.apache.org/jira/browse/IGNITE-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16101: --- Priority: Blocker (was: Critical) > Update Ignite dependency log4j > -- > > Key: IGNITE-16101 > URL: https://issues.apache.org/jira/browse/IGNITE-16101 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Blocker > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency: log4j to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16101) Update Ignite dependency log4j
[ https://issues.apache.org/jira/browse/IGNITE-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16101: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Update Ignite dependency log4j > -- > > Key: IGNITE-16101 > URL: https://issues.apache.org/jira/browse/IGNITE-16101 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency: log4j to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16101) Update Ignite dependency log4j
[ https://issues.apache.org/jira/browse/IGNITE-16101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16101: - Fix Version/s: 2.12 > Update Ignite dependency log4j > -- > > Key: IGNITE-16101 > URL: https://issues.apache.org/jira/browse/IGNITE-16101 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency: log4j to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15564) [Ignite 3] Properly inject names into named list elements
[
https://issues.apache.org/jira/browse/IGNITE-15564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457157#comment-17457157
]
Semyon Danilov commented on IGNITE-15564:
-
LGTM! Thanks for the contribution, merged to main
> [Ignite 3] Properly inject names into named list elements
> -
>
> Key: IGNITE-15564
> URL: https://issues.apache.org/jira/browse/IGNITE-15564
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> h3. Problem
> Current design of named lists has a flaw that is best shown in classes like
> "TableConfigurationSchema". It's the field called "name". Simple table
> configuration would look like this (prefix "table.tables" looks bad BTW):
> {code:java}
> table.tables : {
> foo : {
> name = foo,
> etc...
> }
> }{code}
> Table name must be duplicated and I actually doubt that we validate names
> equality. Same applies to columns and indexes. There's probably more, I
> didn't check.
> Obviously, developers want to access named list element name inside of the
> element itself. And there's no API for that.
> h3. Approach
> Proper solution would be annotating name fields:
> {code:java}
> @Config
> public class TableConfigurationSchema {
> @InjectedName // temporary title, maybe there are better options
> public String name = "default";
> ...
> }{code}
> Injected name must be a string. It's treated like "@Value" field BUT has no
> "update" method associated with it. Basically, name is considered immutable
> and "explicitly uninitializable" in this context. So how do you initialize it
> then?
> * if schema is used as a named list - name is passed into "create*"/"rename"
> methods. Field is automatically updated after that.
> * if schema if used as a regular config value, we have two options:
> ** generate special extended interfaces that will in fact have setters for
> names. These will only be used for "non-named-list" values;
> ** always use default value provided in either schema itself (as in example)
> or in "@Value(name = "default") if it makes any sense. This option looks
> better for me and it's easier to implement.
> h3. Implementation notes
> Compile-time code generation is easy, just reuse already existing methods and
> add few "if" clauses.
> I don't think that methods like "traverse*" or "construct*" should process
> name fields. So there's a filtering to be done in ConfigurationAsmGenerator.
> "NamedConfigValue#syntheticKeyName" should probably be removed. Instead we
> should use injected field name or just "name" if there's none. Otherwise
> there will be a confusion.
> All classes that use constant "NamedListNode#NAME" are a subject to
> modification. There's a high chance that they will inject values for
> annotated fields. Maybe we need a new method in "InnerNode" for this, it's
> not clear yet.
> Classes that implement ConfigurationSource should be carefully examined as
> well, especially HOCON* ones.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15721) Effective way of retrieving tables by id.
[
https://issues.apache.org/jira/browse/IGNITE-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-15721:
Assignee: Kirill Tkalenko (was: Ivan Bessonov)
> Effective way of retrieving tables by id.
> ---
>
> Key: IGNITE-15721
> URL: https://issues.apache.org/jira/browse/IGNITE-15721
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha3
>Reporter: Alexander Lapin
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: Configuration, iep-55, ignite-3
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Problem
> There are use cases that suppose retrieving configuration entities by id. For
> example retrieving table by id. The only option now is to get all tables with
> further iteration that will check whether a table id matches expected one.
> Things get worse if it's required to get table by id from remote node, e.g.
> {code:java}
> private boolean isTableConfigured(IgniteUuid id) {
> NamedListView directTablesCfg =
> ((DirectConfigurationProperty>)tablesCfg.tables()).directValue();
> // TODO: IGNITE-15721 Need to review this approach after the ticket
> would be fixed.
> // Probably, it won't be required getting configuration of all tables
> from Metastor.
> for (String name : directTablesCfg.namedListKeys()) {
> ExtendedTableView tView =
> (ExtendedTableView)directTablesCfg.get(name);
> if (tView != null && id.equals(IgniteUuid.fromString(tView.id(
> return true;
> }
> return false;
> }
> {code}
> It worth to mention that sometimes, for example in use case mentioned above,
> exact data aren't needed, cause only fact of data absence is important. In
> other words It'll be great not only to have ability to retrieve tables,
> columns, indexes and other named list items by id (in addition to retrieving
> by name) but also check whether required entity exists or not. Both local and
> direct use cases are important.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16097) Some tests are flaky in ItNodeTest
[ https://issues.apache.org/jira/browse/IGNITE-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-16097: -- Assignee: Sergey Uttsel > Some tests are flaky in ItNodeTest > -- > > Key: IGNITE-16097 > URL: https://issues.apache.org/jira/browse/IGNITE-16097 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > > Some tests are flaky in org.apache.ignite.raft.jraft.core.ItNodeTest: > # testLeaderTransferWithReplicatorStateListener > # testTripleNodesWithReplicatorStateListener > # testResetLearners > # testLeaderTransfer > # testLeaderTransferBeforeLogIsCompleted > # testLeaderTransferResumeOnFailure > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16097) Some tests are flaky in ItNodeTest
[ https://issues.apache.org/jira/browse/IGNITE-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-16097: -- Assignee: (was: Sergey Uttsel) > Some tests are flaky in ItNodeTest > -- > > Key: IGNITE-16097 > URL: https://issues.apache.org/jira/browse/IGNITE-16097 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Priority: Major > > Some tests are flaky in org.apache.ignite.raft.jraft.core.ItNodeTest: > # testLeaderTransferWithReplicatorStateListener > # testTripleNodesWithReplicatorStateListener > # testResetLearners > # testLeaderTransfer > # testLeaderTransferBeforeLogIsCompleted > # testLeaderTransferResumeOnFailure > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15569) Calcite. JOIN with USING fails.
[
https://issues.apache.org/jira/browse/IGNITE-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457135#comment-17457135
]
Evgeny Stanilovsky commented on IGNITE-15569:
-
[~korlov] plz take a look too ?
> Calcite. JOIN with USING fails.
> ---
>
> Key: IGNITE-15569
> URL: https://issues.apache.org/jira/browse/IGNITE-15569
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> statement ok
> CREATE TABLE t1 (a INTEGER, b INTEGER)
> statement ok
> INSERT INTO t1 VALUES (1, 2)
> statement ok
> CREATE TABLE t2 (b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t2 VALUES (2, 3)
> statement ok
> CREATE TABLE t3 (c INTEGER, d INTEGER)
> statement ok
> INSERT INTO t3 VALUES (3, 4)
> query
> SELECT * FROM t1 JOIN t2 USING (b) JOIN t3 USING (c) ORDER BY 1, 2, 3, 4;
>
> 1 2 3 4
> {noformat}
> fails with
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 7
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Permute.permute(SqlValidatorImpl.java:7084)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:662)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:424)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4414)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3657)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:182)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16102) Store all RocksDB partitions in a single column family.
Ivan Bessonov created IGNITE-16102: -- Summary: Store all RocksDB partitions in a single column family. Key: IGNITE-16102 URL: https://issues.apache.org/jira/browse/IGNITE-16102 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-alpha3 Reporter: Ivan Bessonov Current storage implementation puts each partition in its own column family. This effectively means that every partition lives in it's own database, sharing only WAL and some in-memory resources. Given that each column family has multiple files for LSM trees, the amount of opened file descriptors is bigger than it needs to be. Now, the idea is to have a single column family for partitions within a table. And we should think of possibility of storing several tables in the same RocksDB instance, for similar reasons. You can think about is as of cache groups in Ignite 2.x. There's also an "optimization" to be implemented that is missing in code - using key hashes as prefixes. h3. What should be implemented: First of all, code will be heavily refactored. This will lead to simplifications in many places. Otherwise, I see the following list of goals to achieve: * current implementation allows to derive the list of partitions from the list of column families. This won't be possible, I suggest storing this list explicitly in "meta" CF, in any format that'll be convenient during the implementation * there should be a way of having compact "tableId" representation. IgniteUUID or even UUID is too much I think, but it might work as a basis. This problem should be discussed * binary representation for keys should now include following information: ** tableId - fixed-length set of bytes to be used as a prefix ** partitionId - 2 bytes that will follow the tableId. This layout will allow making range queries for specific partitions of specific tables ** key hash - 4 bytes. This one is required to optimize comparison time for keys. Generally speaking, it's safe to assume that hashes will be mostly different for different keys, meaning that hashes will be enough to determine keys inequality ** actual key payload goes after all these prefixes -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15792) Update README.md with Mappers explanation.
[ https://issues.apache.org/jira/browse/IGNITE-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457127#comment-17457127 ] Yury Gerzhedovich commented on IGNITE-15792: [~amashenkov], LGTM > Update README.md with Mappers explanation. > -- > > Key: IGNITE-15792 > URL: https://issues.apache.org/jira/browse/IGNITE-15792 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 10m > Remaining Estimate: 0h > > Update README.md with a short description of Mappers API. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16101) Update Ignite dependency log4j
Aleksandr created IGNITE-16101: -- Summary: Update Ignite dependency log4j Key: IGNITE-16101 URL: https://issues.apache.org/jira/browse/IGNITE-16101 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Assignee: Aleksandr Update Ignite dependency: log4j to 2.15.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15721) Effective way of retrieving tables by id.
[
https://issues.apache.org/jira/browse/IGNITE-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15721:
---
Affects Version/s: 3.0.0-alpha3
> Effective way of retrieving tables by id.
> ---
>
> Key: IGNITE-15721
> URL: https://issues.apache.org/jira/browse/IGNITE-15721
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha3
>Reporter: Alexander Lapin
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: Configuration, iep-55, ignite-3
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Problem
> There are use cases that suppose retrieving configuration entities by id. For
> example retrieving table by id. The only option now is to get all tables with
> further iteration that will check whether a table id matches expected one.
> Things get worse if it's required to get table by id from remote node, e.g.
> {code:java}
> private boolean isTableConfigured(IgniteUuid id) {
> NamedListView directTablesCfg =
> ((DirectConfigurationProperty>)tablesCfg.tables()).directValue();
> // TODO: IGNITE-15721 Need to review this approach after the ticket
> would be fixed.
> // Probably, it won't be required getting configuration of all tables
> from Metastor.
> for (String name : directTablesCfg.namedListKeys()) {
> ExtendedTableView tView =
> (ExtendedTableView)directTablesCfg.get(name);
> if (tView != null && id.equals(IgniteUuid.fromString(tView.id(
> return true;
> }
> return false;
> }
> {code}
> It worth to mention that sometimes, for example in use case mentioned above,
> exact data aren't needed, cause only fact of data absence is important. In
> other words It'll be great not only to have ability to retrieve tables,
> columns, indexes and other named list items by id (in addition to retrieving
> by name) but also check whether required entity exists or not. Both local and
> direct use cases are important.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-15926) Implement two methods for dropping a table for the table existing and not
[
https://issues.apache.org/jira/browse/IGNITE-15926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov resolved IGNITE-15926.
---
Resolution: Won't Fix
We don't need to provide separate method for every case. Mentioned
functionality could be achieved by simply catching an exception and ignoring
it, if needed.
> Implement two methods for dropping a table for the table existing and not
> -
>
> Key: IGNITE-15926
> URL: https://issues.apache.org/jira/browse/IGNITE-15926
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> ANSI standard requires two methods for dropping table for the two DDL:
> _DROP TABLE [ IF EXISTS ] syntax_
> for the purpose, Table manager should provide two methods with similar
> semantic.
> {code}
> TableManager#dropTable(String) throws TableNotExists
> TableManager#dropTableIfExists(String)
> {code}
> Also we need to support [1] ALTER TABLE [ IF EXISTS ] [ADD|DROP|ALTER] COLUMN
> [1] https://postgrespro.ru/docs/postgrespro/9.6/sql-altertable
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16077) Calcite engine. Index on DATE/TIME/TIMESTAMP fields cannot be used
[
https://issues.apache.org/jira/browse/IGNITE-16077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457115#comment-17457115
]
Taras Ledkov commented on IGNITE-16077:
---
[~alex_pl], OK with me.
> Calcite engine. Index on DATE/TIME/TIMESTAMP fields cannot be used
> --
>
> Key: IGNITE-16077
> URL: https://issues.apache.org/jira/browse/IGNITE-16077
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> create table t(d date)
> create index my_index on t(d);
> insert into t values (date '2021-01-01')
> insert into t values (date '2021-01-02')
> select * from t where d = date '2021-01-01'
> {noformat}
> Fails with:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> wrap object into H2 Value. java.lang.Integer cannot be cast to java.sql.Date
> at
> org.apache.ignite.internal.processors.query.h2.index.keys.H2ValueWrapperMixin.wrapToValue(H2ValueWrapperMixin.java:37)
> at
> org.apache.ignite.internal.processors.query.h2.index.keys.DateIndexKey.(DateIndexKey.java:31)
> at
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory.wrap(IndexKeyFactory.java:95)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:173)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:58)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.AbstractIndexScan.iterator(AbstractIndexScan.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.iterator(IndexScan.java:145)
> {noformat}
> We should convert DATE/TIME/TIMESTAMP from internal presentation (see
> {{TypeUtils.fromInternal()}}) before creating {{IndexRow}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
5. Introduce distributed property to disable these validation for backward
compatibility.
was:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
5. Introduce distributed property to disable these validation to backward
compatibility.
was:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding
[jira] [Commented] (IGNITE-15922) Create numa-aware allocator for data regions.
[
https://issues.apache.org/jira/browse/IGNITE-15922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457110#comment-17457110
]
Ivan Daschinsky commented on IGNITE-15922:
--
[~zstan] Thanks a lot, I've fixed some of them, others are answered.
> Create numa-aware allocator for data regions.
> -
>
> Key: IGNITE-15922
> URL: https://issues.apache.org/jira/browse/IGNITE-15922
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> Sometimes it is worth to allocate data region on specific numa node or on
> interleaved node (i.e. Intel Optane can be set up as a little bit slower, but
> cheaper than and have more capacity, than DDR, and unified as NUMA nodes).
> Need to write C++ wrapper around {{libnuma}} and extract common allocator
> interface and add as a configuration parameter to {{DataRegionConfiguration}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion on the node locally.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
was:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}}
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that break the consistency between indexes and data and can
cause the index tree to break.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
was:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Summary: Key type and schema must be validated on a data insertion (was:
Key type and schema must be validated on a data inserttion)
> Key type and schema must be validated on a data insertion
> -
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
>
> There are two cases that breaks consistency between indexes and data and may
> be cause of break index tree.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types*
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#valueType}} the entity is not
> indexed (not applied fr the table).
> But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
> fields of inserted entry are validated.
> Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
> different types. Such insertion produce critical error.
> But this property is set up on the first insertion.
> So, the steps to fail:
> 1. Put key with type "Key0" on the one node - OK;
> 2. Put key with type "Key1" on the other node - OK;
> 3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
> build index);
> *Suggestion fix:*
> 1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the second case);
> 2. *Before* table creation register {{BinaryMetadata}} for specified key type;
> 3. If the type corresponding for KEY is already registered and schemas differ
> - fail the table creation;
> 3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
> cluster-wide propagation and store at the persistence configuration;
> 4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the first case)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data inserttion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. *Before* table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
was:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. On table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}}
[jira] [Assigned] (IGNITE-15994) Create NUMA allocator test suite.
[
https://issues.apache.org/jira/browse/IGNITE-15994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Ivanov reassigned IGNITE-15994:
Assignee: Ivan Daschinsky (was: Petr Ivanov)
> Create NUMA allocator test suite.
> -
>
> Key: IGNITE-15994
> URL: https://issues.apache.org/jira/browse/IGNITE-15994
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>
> Need to create specific suite on TC 1, link to existing suite in TC 2 is in
> links.
> Suite should be excluded from {{Run All}} until merge of IGNITE-15922
> [PR|https://github.com/apache/ignite/pull/9569] for testing
> Module name: {{:ignite-numa-allocator}}
> Test suite name: {{NumaAllocatorTestSuite}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15994) Create NUMA allocator test suite.
[
https://issues.apache.org/jira/browse/IGNITE-15994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457095#comment-17457095
]
Petr Ivanov commented on IGNITE-15994:
--
Looks good, thanks for contribution.
> Create NUMA allocator test suite.
> -
>
> Key: IGNITE-15994
> URL: https://issues.apache.org/jira/browse/IGNITE-15994
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Daschinsky
>Assignee: Petr Ivanov
>Priority: Major
>
> Need to create specific suite on TC 1, link to existing suite in TC 2 is in
> links.
> Suite should be excluded from {{Run All}} until merge of IGNITE-15922
> [PR|https://github.com/apache/ignite/pull/9569] for testing
> Module name: {{:ignite-numa-allocator}}
> Test suite name: {{NumaAllocatorTestSuite}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15922) Create numa-aware allocator for data regions.
[
https://issues.apache.org/jira/browse/IGNITE-15922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457085#comment-17457085
]
Evgeny Stanilovsky commented on IGNITE-15922:
-
[~ivandasch] i left some comment, plz check them, overall looks good.
> Create numa-aware allocator for data regions.
> -
>
> Key: IGNITE-15922
> URL: https://issues.apache.org/jira/browse/IGNITE-15922
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Sometimes it is worth to allocate data region on specific numa node or on
> interleaved node (i.e. Intel Optane can be set up as a little bit slower, but
> cheaper than and have more capacity, than DDR, and unified as NUMA nodes).
> Need to write C++ wrapper around {{libnuma}} and extract common allocator
> interface and add as a configuration parameter to {{DataRegionConfiguration}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data inserttion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
*Suggestion fix:*
1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the second case);
2. On table creation register {{BinaryMetadata}} for specified key type;
3. If the type corresponding for KEY is already registered and schemas differ -
fail the table creation;
3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
cluster-wide propagation and store at the persistence configuration;
4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
(fixes the first case)
was:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
> Key type and schema must be validated on a data inserttion
> --
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter:
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data inserttion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion.
So, the steps to fail:
1. Put key with type "Key0" on the one node - OK;
2. Put key with type "Key1" on the other node - OK;
3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
build index);
was:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion. May be it is implemented
> Key type and schema must be validated on a data inserttion
> --
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
>
> There are two cases that breaks consistency between indexes and data and may
> be cause of break index tree.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
>
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data inserttion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#valueType}} the entity is not indexed
(not applied fr the table).
But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
fields of inserted entry are validated.
Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
different types. Such insertion produce critical error.
But this property is set up on the first insertion. May be it is implemented
was:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#keyType}} the entity is not indexed
(not applied fr the table).
> Key type and schema must be validated on a data inserttion
> --
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
>
> There are two cases that breaks consistency between indexes and data and may
> be cause of break index tree.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
>
[jira] [Created] (IGNITE-16100) Support case-insensitive mapping fields to columns by names.
Andrey Mashenkov created IGNITE-16100: - Summary: Support case-insensitive mapping fields to columns by names. Key: IGNITE-16100 URL: https://issues.apache.org/jira/browse/IGNITE-16100 Project: Ignite Issue Type: Wish Reporter: Andrey Mashenkov Let's add a possibility to use case insensitive comparison when mapping object fields to columns by their names. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data inserttion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types*
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#keyType}} the entity is not indexed
(not applied fr the table).
was:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types *
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#keyType}} the entity is not indexed
(not applied fr the table).
> Key type and schema must be validated on a data inserttion
> --
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
>
> There are two cases that breaks consistency between indexes and data and may
> be cause of break index tree.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types*
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#keyType}} the entity is not
> indexed (not applied fr the table).
--
This
[jira] [Created] (IGNITE-16099) org.apache.ignite.internal.configuration.processor.Processor refactoring: move validation into a separate class
Kirill Tkalenko created IGNITE-16099: Summary: org.apache.ignite.internal.configuration.processor.Processor refactoring: move validation into a separate class Key: IGNITE-16099 URL: https://issues.apache.org/jira/browse/IGNITE-16099 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-alpha3 Reporter: Kirill Tkalenko The code in *org.apache.ignite.internal.configuration.processor.Processor* is growing more and more, it is necessary to move the validation of classes/fields to a separate class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16096) Implement MVCC support to avoid excessive locking
[ https://issues.apache.org/jira/browse/IGNITE-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-16096: --- Description: We need to implement MVCC support to avoid locking and resulting conflicts. Generally, the idea is to use monotonic timestamps to globally order the transactions. See [1][2] for decentralized timestamp generation techniques, [3]for MVCC analysis: [1] [http://users.ece.utexas.edu/~garg/pdslab/david/hybrid-time-tech-report-01.pdf] [2] [https://www.usenix.org/system/files/nsdi21-wei.pdf] [3] [http://www.vldb.org/pvldb/vol10/p781-Wu.pdf] was: We need to implement MVCC support to avoid locking. Generally, the idea is to use monotonic timestamps to globally order the transactions. See [1][2] for decentralized timestamp generation techniques, [3]for MVCC analysis: [1] [http://users.ece.utexas.edu/~garg/pdslab/david/hybrid-time-tech-report-01.pdf] [2] [https://www.usenix.org/system/files/nsdi21-wei.pdf] [3] http://www.vldb.org/pvldb/vol10/p781-Wu.pdf > Implement MVCC support to avoid excessive locking > - > > Key: IGNITE-16096 > URL: https://issues.apache.org/jira/browse/IGNITE-16096 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > > We need to implement MVCC support to avoid locking and resulting conflicts. > Generally, the idea is to use monotonic timestamps to globally order the > transactions. > See [1][2] for decentralized timestamp generation techniques, [3]for MVCC > analysis: > [1] > [http://users.ece.utexas.edu/~garg/pdslab/david/hybrid-time-tech-report-01.pdf] > [2] [https://www.usenix.org/system/files/nsdi21-wei.pdf] > [3] [http://www.vldb.org/pvldb/vol10/p781-Wu.pdf] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data inserttion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16098:
--
Description:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
Now this case is applied only for SQL CREATE TABLE and cannot be reproduced via
cache API.
Because PK fields are unwrap only for SQL tables.
Different functions of the cache API and SQL API should be fixed by
IGNITE-11402.
It should be possible to create identical tables by SQL and cache API.
*2. Object with different key types *
Now the value type is specify the table. If the value type doesn't not equal to
value type specified by the {{QueryEntity#keyType}} the entity is not indexed
(not applied fr the table).
was:
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
> Key type and schema must be validated on a data inserttion
> --
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
>
> There are two cases that breaks consistency between indexes and data and may
> be cause of break index tree.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types *
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#keyType}} the entity is not
> indexed (not applied fr the table).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15907) Remove deprecated code in 3.0 related to the old serializer.
[ https://issues.apache.org/jira/browse/IGNITE-15907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457078#comment-17457078 ] Yury Gerzhedovich commented on IGNITE-15907: [~amashenkov], LGTM in general. Let's add JIRA links for TODOs and may be we should think out the possibility ignore case mode for column names at mappers (as a separate ticket). > Remove deprecated code in 3.0 related to the old serializer. > > > Key: IGNITE-15907 > URL: https://issues.apache.org/jira/browse/IGNITE-15907 > Project: Ignite > Issue Type: Task >Reporter: Yury Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Trivial > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 50m > Remaining Estimate: 0h > > Despite don't have a GA release we already have many deprecated part of code. > Let's fix generated serializer and remove deprecated code. > Just find '@deprecated' -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16098) Key type and schema must be validated on a data inserttion
Taras Ledkov created IGNITE-16098:
-
Summary: Key type and schema must be validated on a data inserttion
Key: IGNITE-16098
URL: https://issues.apache.org/jira/browse/IGNITE-16098
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.11
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.13
There are two cases that breaks consistency between indexes and data and may be
cause of break index tree.
*1. Put different entities that are logically same for SQL*
{{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int) WITH
"KEY_TYPE=MyType,CACHE_NAME=test"}};
then create to keys with hidden field and put to cache test.
{code}
BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 0);
BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
bobKey0.setField("ID0", 0);
bobKey0.setField("ID1", 0);
bobKey0.setField("hidden", 1);
{code}
These key object are different by hidden field and cache will contains two
entries.
But (ID0, ID1) fields are same and sorted PK index will contain only one record.
--
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=17457068#comment-17457068
]
Nikolay Izhikov commented on IGNITE-16057:
--
[~vermakov] Yes. I will take a look shortly.
> 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] [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=17457065#comment-17457065
]
Taras Ledkov commented on IGNITE-16057:
---
[~vermakov], the patch is OK with me.
> 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] [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] [Commented] (IGNITE-16046) Calcite engine. Double JOIN hangs on optimization phase
[
https://issues.apache.org/jira/browse/IGNITE-16046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457030#comment-17457030
]
Ivan Daschinsky commented on IGNITE-16046:
--
[~korlov] [~tledkov] Patch for debug is attached.
> Calcite engine. Double JOIN hangs on optimization phase
> ---
>
> Key: IGNITE-16046
> URL: https://issues.apache.org/jira/browse/IGNITE-16046
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Attachments: IGNITE-16046_Combinatorial_explosions.patch
>
>
> Reproducer:
> {noformat}
> CREATE TABLE T1(A INT, B INT);
> CREATE TABLE T2(A INT, C INT);
> CREATE TABLE T3(B INT, C INT);
> SELECT * FROM T1 JOIN T2 ON (T1.A = T2.A) JOIN T3 ON (T1.B = T3.B AND T2.C =
> T3.C);
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16046) Calcite engine. Double JOIN hangs on optimization phase
[
https://issues.apache.org/jira/browse/IGNITE-16046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-16046:
-
Attachment: IGNITE-16046_Combinatorial_explosions.patch
> Calcite engine. Double JOIN hangs on optimization phase
> ---
>
> Key: IGNITE-16046
> URL: https://issues.apache.org/jira/browse/IGNITE-16046
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Attachments: IGNITE-16046_Combinatorial_explosions.patch
>
>
> Reproducer:
> {noformat}
> CREATE TABLE T1(A INT, B INT);
> CREATE TABLE T2(A INT, C INT);
> CREATE TABLE T3(B INT, C INT);
> SELECT * FROM T1 JOIN T2 ON (T1.A = T2.A) JOIN T3 ON (T1.B = T3.B AND T2.C =
> T3.C);
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14299) .NET: Service loses array type information
[
https://issues.apache.org/jira/browse/IGNITE-14299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14299:
-
Fix Version/s: 2.13
> .NET: Service loses array type information
> --
>
> Key: IGNITE-14299
> URL: https://issues.apache.org/jira/browse/IGNITE-14299
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: .NET
> Fix For: 2.13
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> In case .Net -> .Net service call Ignite loses array type information.
> {code:java}
> using Apache.Ignite.Core;
> using Apache.Ignite.Core.Discovery.Tcp;
> using Apache.Ignite.Core.Discovery.Tcp.Static;
> using Apache.Ignite.Core.Services;
> using Castle.DynamicProxy;
> using System;
> using System.Linq;
> using Xunit;
> namespace Ignite.ServiceReturnsArray
> {
> public class Test : IDisposable
> {
> private readonly IIgnite igniteSrv;
> private readonly IIgnite ignite;
> public Test()
> {
> IgniteConfiguration IgniteConfig(bool clientMode) => new
> IgniteConfiguration()
> {
> ClientMode = clientMode,
> IgniteInstanceName = Guid.NewGuid().ToString(),
> DiscoverySpi = new TcpDiscoverySpi
> {
> IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
> new[] { "127.0.0.1:47500" } }
> }
> };
> igniteSrv = Ignition.Start(IgniteConfig(false));
> ignite = Ignition.Start(IgniteConfig(true));
>
> ignite.GetServices().DeployClusterSingleton(nameof(ArrayFactoryService), new
> ArrayFactoryService());
> }
> public void Dispose()
> {
> ignite.Dispose();
> igniteSrv.Dispose();
> }
> [Fact]
> public void ServiceReturnsArray()
> {
> var arr =
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService),
> false)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithReflection()
> {
> var arr =
> typeof(IArrayFactory).GetMethod(nameof(IArrayFactory.CreateArray)).Invoke(
>
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService)),
> new object[] { 2, 1 });
> Assert.IsType(arr);
> Assert.Equal(1, ((Result[])arr)?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithCastleProxy()
> {
> var interceptor = new ServiceInterceptor(ignite,
> nameof(ArrayFactoryService));
>
> var arr = new
> ProxyGenerator().CreateInterfaceProxyWithoutTarget(interceptor)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> public sealed class Result
> {
> public int Value { get; set; }
> }
> public interface IArrayFactory
> {
> Result[] CreateArray(int size, int dlftVal);
> }
> public sealed class ArrayFactoryService : IArrayFactory, IService
> {
> public Result[] CreateArray(int size, int dfltVal)
> {
> return Enumerable.Repeat(new Result { Value = dfltVal },
> size).ToArray();
> }
> public void Cancel(IServiceContext context)
> {
> }
> public void Execute(IServiceContext context)
> {
> }
> public void Init(IServiceContext context)
> {
> }
> }
> private sealed class ServiceInterceptor : IInterceptor where T:
> class
> {
> private readonly IIgnite ignite;
> private readonly string name;
> public ServiceInterceptor(IIgnite ignite, string name)
> {
> this.ignite = ignite;
> this.name = name;
> }
> public void Intercept(IInvocation invocation)
> {
> var svc = ignite.GetServices().GetServiceProxy(name,
> false);
> invocation.ReturnValue = invocation.Method.Invoke(svc,
> invocation.Arguments);
> }
> }
> }
> }
> {code}
>
> Above test fail on type check.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16076) .NET: Remove duplicate test class
[ https://issues.apache.org/jira/browse/IGNITE-16076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-16076: - Fix Version/s: 2.13 > .NET: Remove duplicate test class > - > > Key: IGNITE-16076 > URL: https://issues.apache.org/jira/browse/IGNITE-16076 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Trivial > Fix For: 2.13 > > Time Spent: 50m > Remaining Estimate: 0h > > PlatformBinarizable defined two times in tests. > This means when using SimpleNameMapper two different classes messed up during > tests execution. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16090) ItMetadataTest.columnOrder cannot be run twice in the same JVM
[
https://issues.apache.org/jira/browse/IGNITE-16090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16090:
-
Description:
The attempt to run the _ItMetadataTest.columnOrder_ test twice in the same JVM
results in the following exception:
{noformat}
class org.apache.ignite.lang.IgniteException: An error occurred while query
executing.
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.checkException(RootNode.java:278)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.exchangeBuffers(RootNode.java:265)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.hasNext(RootNode.java:189)
at
org.apache.ignite.internal.processors.query.calcite.exec.ClosableIteratorsHolder$DelegatingIterator.hasNext(ClosableIteratorsHolder.java:132)
at
org.apache.ignite.internal.processors.query.calcite.util.TransformingIterator.hasNext(TransformingIterator.java:44)
at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
at
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
at
org.apache.ignite.internal.calcite.util.Commons.getAllFromCursor(Commons.java:31)
at
org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:380)
at
org.apache.ignite.internal.calcite.ItMetadataTest.columnOrder(ItMetadataTest.java:106)
...
Caused by: java.lang.NullPointerException: table
at java.base/java.util.Objects.requireNonNull(Objects.java:246)
at org.apache.calcite.rel.core.TableScan.(TableScan.java:72)
at org.apache.calcite.rel.core.TableScan.(TableScan.java:90)
at
org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.(ProjectableFilterableTableScan.java:89)
at
org.apache.ignite.internal.processors.query.calcite.rel.IgniteTableScan.(IgniteTableScan.java:44)
at SC.apply(Unknown Source)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJson$RelFactory.apply(RelJson.java:117)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRel(RelJsonReader.java:126)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRels(RelJsonReader.java:117)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.read(RelJsonReader.java:108)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.fromJson(RelJsonReader.java:81)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareFragment(ExecutionServiceImpl.java:404)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$onMessage$6(ExecutionServiceImpl.java:582)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.lambda$queryPlan$0(QueryPlanCacheImpl.java:47)
at
com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
at
java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
at
com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
at
com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
at
com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:47)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:580)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$start$1(ExecutionServiceImpl.java:189)
at
org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:154)
at
org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:124)
at
org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:78)
at
[jira] [Commented] (IGNITE-14299) .NET: Service loses array type information
[
https://issues.apache.org/jira/browse/IGNITE-14299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17456994#comment-17456994
]
Nikolay Izhikov commented on IGNITE-14299:
--
https://ci2.ignite.apache.org/viewLog.html?buildId=6226735=IgniteTests24Java8_RunAllNet
- final tests run.
> .NET: Service loses array type information
> --
>
> Key: IGNITE-14299
> URL: https://issues.apache.org/jira/browse/IGNITE-14299
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: .NET
> Time Spent: 4h
> Remaining Estimate: 0h
>
> In case .Net -> .Net service call Ignite loses array type information.
> {code:java}
> using Apache.Ignite.Core;
> using Apache.Ignite.Core.Discovery.Tcp;
> using Apache.Ignite.Core.Discovery.Tcp.Static;
> using Apache.Ignite.Core.Services;
> using Castle.DynamicProxy;
> using System;
> using System.Linq;
> using Xunit;
> namespace Ignite.ServiceReturnsArray
> {
> public class Test : IDisposable
> {
> private readonly IIgnite igniteSrv;
> private readonly IIgnite ignite;
> public Test()
> {
> IgniteConfiguration IgniteConfig(bool clientMode) => new
> IgniteConfiguration()
> {
> ClientMode = clientMode,
> IgniteInstanceName = Guid.NewGuid().ToString(),
> DiscoverySpi = new TcpDiscoverySpi
> {
> IpFinder = new TcpDiscoveryStaticIpFinder { Endpoints =
> new[] { "127.0.0.1:47500" } }
> }
> };
> igniteSrv = Ignition.Start(IgniteConfig(false));
> ignite = Ignition.Start(IgniteConfig(true));
>
> ignite.GetServices().DeployClusterSingleton(nameof(ArrayFactoryService), new
> ArrayFactoryService());
> }
> public void Dispose()
> {
> ignite.Dispose();
> igniteSrv.Dispose();
> }
> [Fact]
> public void ServiceReturnsArray()
> {
> var arr =
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService),
> false)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithReflection()
> {
> var arr =
> typeof(IArrayFactory).GetMethod(nameof(IArrayFactory.CreateArray)).Invoke(
>
> ignite.GetServices().GetServiceProxy(nameof(ArrayFactoryService)),
> new object[] { 2, 1 });
> Assert.IsType(arr);
> Assert.Equal(1, ((Result[])arr)?[1]?.Value);
> }
> [Fact]
> public void ServiceReturnsArrayWithCastleProxy()
> {
> var interceptor = new ServiceInterceptor(ignite,
> nameof(ArrayFactoryService));
>
> var arr = new
> ProxyGenerator().CreateInterfaceProxyWithoutTarget(interceptor)
> .CreateArray(2, 1);
> Assert.IsType(arr);
> Assert.Equal(1, arr?[1]?.Value);
> }
> public sealed class Result
> {
> public int Value { get; set; }
> }
> public interface IArrayFactory
> {
> Result[] CreateArray(int size, int dlftVal);
> }
> public sealed class ArrayFactoryService : IArrayFactory, IService
> {
> public Result[] CreateArray(int size, int dfltVal)
> {
> return Enumerable.Repeat(new Result { Value = dfltVal },
> size).ToArray();
> }
> public void Cancel(IServiceContext context)
> {
> }
> public void Execute(IServiceContext context)
> {
> }
> public void Init(IServiceContext context)
> {
> }
> }
> private sealed class ServiceInterceptor : IInterceptor where T:
> class
> {
> private readonly IIgnite ignite;
> private readonly string name;
> public ServiceInterceptor(IIgnite ignite, string name)
> {
> this.ignite = ignite;
> this.name = name;
> }
> public void Intercept(IInvocation invocation)
> {
> var svc = ignite.GetServices().GetServiceProxy(name,
> false);
> invocation.ReturnValue = invocation.Method.Invoke(svc,
> invocation.Arguments);
> }
> }
> }
> }
> {code}
>
> Above test fail on type check.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16097) Some tests are flaky in ItNodeTest
Sergey Uttsel created IGNITE-16097: -- Summary: Some tests are flaky in ItNodeTest Key: IGNITE-16097 URL: https://issues.apache.org/jira/browse/IGNITE-16097 Project: Ignite Issue Type: Task Reporter: Sergey Uttsel Assignee: Sergey Uttsel Some tests are flaky in org.apache.ignite.raft.jraft.core.ItNodeTest: # testLeaderTransferWithReplicatorStateListener # testTripleNodesWithReplicatorStateListener # testResetLearners # testLeaderTransfer # testLeaderTransferBeforeLogIsCompleted # testLeaderTransferResumeOnFailure -- This message was sent by Atlassian Jira (v8.20.1#820001)
