You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2013/08/21 16:11:59 UTC
[jira] [Commented] (CASSANDRA-5882) Changing column type from int
to bigint or vice versa causes decoding errors.
[ https://issues.apache.org/jira/browse/CASSANDRA-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13746070#comment-13746070 ]
Sylvain Lebresne commented on CASSANDRA-5882:
---------------------------------------------
The reason is that we currently don't validate anything when a non-PK column type is altered, which is probably a mistake (at least imo). There's an historical reason for that: thrift doesn't validate such change either. So in a way, that's not a new thing: if you change a validator for an incompatible one (which is the case here, int (Int32Type) is not able to decode most value of bigint (IntegerType)), you'll likely break your client code (which is the case btw, it's a cqlsh error here, not a server side one).
So I would personally be in favor of just refusing that kind of change pure and simple. Attaching a simple patch to do that (for CQL3 only since Thou Shalt Not Modify Thrift).
> Changing column type from int to bigint or vice versa causes decoding errors.
> -----------------------------------------------------------------------------
>
> Key: CASSANDRA-5882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5882
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: J.B. Langston
> Attachments: 5882.txt
>
>
> cqlsh:dbsite> create table testint (id uuid, bestof bigint, primary key (id) );
> cqlsh:dbsite> insert into testint (id, bestof ) values (49d30f84-a409-4433-ad60-eb9c1a06b7bb, 1376399966);
> cqlsh:dbsite> insert into testint (id, bestof ) values (6cab4798-ad29-4419-bd59-308f9ec3bc44, 1376389800);
> cqlsh:dbsite> insert into testint (id, bestof ) values (685bb9ff-a4fe-4e47-95eb-f6a353d9e179, 1376390400);
> cqlsh:dbsite> insert into testint (id, bestof ) values (a848f832-5ded-4ef7-bf4b-7db561564c57, 1376391000);
> cqlsh:dbsite> select * from testint ;
> id | bestof
> --------------------------------------+------------
> a848f832-5ded-4ef7-bf4b-7db561564c57 | 1376391000
> 49d30f84-a409-4433-ad60-eb9c1a06b7bb | 1376399966
> 6cab4798-ad29-4419-bd59-308f9ec3bc44 | 1376389800
> 685bb9ff-a4fe-4e47-95eb-f6a353d9e179 | 1376390400
> cqlsh:dbsite> alter table testint alter bestof TYPE int;
> cqlsh:dbsite> select * from testint ;
> id | bestof
> --------------------------------------+-----------------------------
> a848f832-5ded-4ef7-bf4b-7db561564c57 | '\x00\x00\x00\x00R\n\x0fX'
> 49d30f84-a409-4433-ad60-eb9c1a06b7bb | '\x00\x00\x00\x00R\n2^'
> 6cab4798-ad29-4419-bd59-308f9ec3bc44 | '\x00\x00\x00\x00R\n\n\xa8'
> 685bb9ff-a4fe-4e47-95eb-f6a353d9e179 | '\x00\x00\x00\x00R\n\r\x00'
> Failed to decode value '\x00\x00\x00\x00R\n\x0fX' (for column 'bestof') as int: unpack requires a string argument of length 4
> Failed to decode value '\x00\x00\x00\x00R\n2^' (for column 'bestof') as int: unpack requires a string argument of length 4
> 2 more decoding errors suppressed.
> I realize that going from BIGINT to INT would cause overflow if a column contained a number larger than 2^31-1, it is at least technically possible to go in the other direction. I also understand that rewriting all the data in the correct format would be a very expensive operation on a large column family, but if that's not something we want to allow we should explicitly disallow changing data types if the table has any rows.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira