phoenix icon indicating copy to clipboard operation
phoenix copied to clipboard

PHOENIX-7282 Incorrect data in index column for corresponding BIGIT t…

Open szucsvillo opened this issue 1 year ago • 2 comments

…ype column in data table

szucsvillo avatar Oct 10 '24 12:10 szucsvillo

Example: create table test203 (mykey integer not null primary key, col1 bigint, new_column_1 FLOAT, new_column_2 DOUBLE, new_column_3 BIGINT); create index indexName203 on test203 (col1) INCLUDE (new_column_1,new_column_2,new_column_3); UPSERT INTO TEST203(mykey,col1,new_column_1,new_column_2,new_column_3) VALUES(5,43,201,202,203); SELECT TENANT_ID, TABLE_SCHEM, TABLE_NAME, DATA_TYPE, COLUMN_NAME, DATA_TABLE_NAME, COLUMN_FAMILY,ORDINAL_POSITION, KEY_SEQ FROM system.catalog WHERE TABLE_NAME = 'INDEXNAME203' or TABLE_NAME = 'TEST203';

phoenix7282_goal

When creating an index like indexName203 on test203 (col1) with included columns (new_column_1, new_column_2, new_column_3), the data types of the included columns in the catalog table do not change to DECIMAL. This is because these columns are only included in the index for retrieval efficiency and are not part of the indexed key, like col1. That's why I made the following changes in AlterAddCascadeIndexIT to ensure the included columns retain their original data types, such as FLOAT or DOUBLE, rather than converting them to DECIMAL, since they are not part of the index key and don't require transformation for indexing purposes.

szucsvillo avatar Oct 10 '24 12:10 szucsvillo

Please rebase @szucsvillo , this doesn't seem to have the fixes my BackwardsCompatibilityIT regression.

I'd like to see a clean(er) CI run before committing.

stoty avatar Oct 21 '24 05:10 stoty

Kicked off another run, as the last one hasn't even made it into the ITs :(

stoty avatar Oct 21 '24 10:10 stoty