[
https://issues.apache.org/jira/browse/CASSANDRA-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742444#comment-14742444
]
Robert Stupp commented on CASSANDRA-10311:
------------------------------------------
Probably related: CASSANDRA-10027
> It looks like our type alterations may be buggy
> -----------------------------------------------
>
> Key: CASSANDRA-10311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10311
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
>
> We should document how type coercion works, in all contexts (UDFs, query
> responses, merging), and what our criteria are for success. Right now it
> looks like we perform no conversion, so we should require that they are
> compared in the same way (if they are clusterings), and that they at least
> have the same number of bytes (if both fixed width).
> Integer type considers itself value compatible with Int32 and Long, which
> from an AlterTable point of view at least seems potentially problematic.
> It's very likely I'm missing something. However as it stands we seem able to
> read an old type from an sstable, have it make it through a compaction
> unscathed, and write out the same bytes "as" the new type. If I'm correct
> about this behaviour, this will corrupt this partition in the new sstable so
> that it cannot be read.
> Not marking as critical/blocker, as I'm not familiar enough with how this
> works to say if this brief analysis is correct, but if I am we should raise
> the priority.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
