You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Ilya Shishkov (Jira)" <ji...@apache.org> on 2022/06/30 18:49:00 UTC
[jira] [Updated] (IGNITE-17285) Ambiguous output of INDEXES SytemView if cache is created via DDL
[ https://issues.apache.org/jira/browse/IGNITE-17285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ilya Shishkov updated IGNITE-17285:
-----------------------------------
Description:
There is a difference 'COLUMNS ' and 'INLINE_SIZE' columns content in system view 'INDEXES' , when you create SQL-cache by means of QueryEntity and by means of DDL.
As you can see in reproducer [^SqlIndexSystemViewReproducerTest.patch] , there are two "equal" attepmts to create cache: via DDL, and via Cache API + QueryEntity.
Primary keys contains equal set of fields, affinity fields are the same. Outputs of system views TABLES, TABLE_COLUMNS and BINARY_METADATA are the same for both ways of cache creation. Table content (i.e. select *) is also the same, if you do not take into account the order of output.
There are example sqlline outputs for table from reproducer:
# [^create_table.txt] - for table, created by DDL.
# [^query_entity.txt] - for table, created by Cache API.
As you can see, colums and content differs in INDEXES view: in case of DDL indexes does not have '_KEY' column, and have explicit set of columns from primary key. In case of creation table via Cache API + QueryEntity, no exlicip column are shown, but 'KEY' column is. Also, there is a duplication of 'ID' column for '_key_PR_hash' index:
{code}
"ID" ASC, "FIRSTNAME" ASC, "LASTNAME" ASC, "ID" ASC
{code}
Reproducer dumps indexes ({{org.h2.index.Index}}) collection content, which is obtained from {{GridH2Table#getIndexes}}. It seems, that information differs in this class too.
Example output:
{code:java|title=Cache API + QueryEntity}
Index name Columns
_key_PK__SCAN_ [_KEY, ID]
_key_PK_hash [_KEY, ID]
_key_PK [_KEY, ID]
AFFINITY_KEY [ID, _KEY]
PERSONINFO_CITYNAME_IDX [CITYNAME, _KEY, ID]
{code}
{code:java|title=DDL}
Index name Columns
_key_PK__SCAN_ [ID, FIRSTNAME, LASTNAME]
_key_PK_hash [_KEY, ID]
_key_PK [ID, FIRSTNAME, LASTNAME]
AFFINITY_KEY [ID, FIRSTNAME, LASTNAME]
PERSONINFO_CITYNAME_IDX [CITYNAME, ID, FIRSTNAME, LASTNAME]
{code}
was:
There is a difference 'COLUMNS ' and 'INLINE_SIZE' columns content in system view 'INDEXES' , when you create SQL-cache by means of QueryEntity and by means of DDL.
As you can see in reproducer [^SqlIndexSystemViewReproducerTest.patch] , there are two "equal" attepmts to create cache: via DDL, and via Cache API + QueryEntity.
Primary keys contains equal set of fields, affinity fields are the same. Outputs of system views TABLES, TABLE_COLUMNS and BINARY_METADATA are the same for both ways of cache creation. Table content (i.e. select *) is also the same, if you do not take into account the order of output.
There are example sqlline outputs for table from reproducer:
# [^create_table.txt] - for table, created by DDL.
# [^query_entity.txt] - for table, created by Cache API.
As you can see, colums and content differs, in case of DDL indexes does not have '_KEY' column, and have explicit set of columns from primary key. In case of creation table via Cache API + QueryEntity, no exlicip column are shown, but 'KEY' column is. Also, there is a duplication of 'ID' column for '_key_PR_hash' index:
{code}
"ID" ASC, "FIRSTNAME" ASC, "LASTNAME" ASC, "ID" ASC
{code}
Reproducer dumps indexes ({{org.h2.index.Index}}) collection content, which is obtained from {{GridH2Table#getIndexes}}. It seems, that information differs in this class too.
Example output:
{code:java|title=Cache API + QueryEntity}
Index name Columns
_key_PK__SCAN_ [_KEY, ID]
_key_PK_hash [_KEY, ID]
_key_PK [_KEY, ID]
AFFINITY_KEY [ID, _KEY]
PERSONINFO_CITYNAME_IDX [CITYNAME, _KEY, ID]
{code}
{code:java|title=DDL}
Index name Columns
_key_PK__SCAN_ [ID, FIRSTNAME, LASTNAME]
_key_PK_hash [_KEY, ID]
_key_PK [ID, FIRSTNAME, LASTNAME]
AFFINITY_KEY [ID, FIRSTNAME, LASTNAME]
PERSONINFO_CITYNAME_IDX [CITYNAME, ID, FIRSTNAME, LASTNAME]
{code}
> Ambiguous output of INDEXES SytemView if cache is created via DDL
> ------------------------------------------------------------------
>
> Key: IGNITE-17285
> URL: https://issues.apache.org/jira/browse/IGNITE-17285
> Project: Ignite
> Issue Type: Bug
> Reporter: Ilya Shishkov
> Priority: Minor
> Attachments: SqlIndexSystemViewReproducerTest.patch, create_table.txt, query_entity.txt
>
>
> There is a difference 'COLUMNS ' and 'INLINE_SIZE' columns content in system view 'INDEXES' , when you create SQL-cache by means of QueryEntity and by means of DDL.
> As you can see in reproducer [^SqlIndexSystemViewReproducerTest.patch] , there are two "equal" attepmts to create cache: via DDL, and via Cache API + QueryEntity.
> Primary keys contains equal set of fields, affinity fields are the same. Outputs of system views TABLES, TABLE_COLUMNS and BINARY_METADATA are the same for both ways of cache creation. Table content (i.e. select *) is also the same, if you do not take into account the order of output.
> There are example sqlline outputs for table from reproducer:
> # [^create_table.txt] - for table, created by DDL.
> # [^query_entity.txt] - for table, created by Cache API.
> As you can see, colums and content differs in INDEXES view: in case of DDL indexes does not have '_KEY' column, and have explicit set of columns from primary key. In case of creation table via Cache API + QueryEntity, no exlicip column are shown, but 'KEY' column is. Also, there is a duplication of 'ID' column for '_key_PR_hash' index:
> {code}
> "ID" ASC, "FIRSTNAME" ASC, "LASTNAME" ASC, "ID" ASC
> {code}
> Reproducer dumps indexes ({{org.h2.index.Index}}) collection content, which is obtained from {{GridH2Table#getIndexes}}. It seems, that information differs in this class too.
> Example output:
> {code:java|title=Cache API + QueryEntity}
> Index name Columns
> _key_PK__SCAN_ [_KEY, ID]
> _key_PK_hash [_KEY, ID]
> _key_PK [_KEY, ID]
> AFFINITY_KEY [ID, _KEY]
> PERSONINFO_CITYNAME_IDX [CITYNAME, _KEY, ID]
> {code}
> {code:java|title=DDL}
> Index name Columns
> _key_PK__SCAN_ [ID, FIRSTNAME, LASTNAME]
> _key_PK_hash [_KEY, ID]
> _key_PK [ID, FIRSTNAME, LASTNAME]
> AFFINITY_KEY [ID, FIRSTNAME, LASTNAME]
> PERSONINFO_CITYNAME_IDX [CITYNAME, ID, FIRSTNAME, LASTNAME]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)