[
https://issues.apache.org/jira/browse/CASSANDRA-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko updated CASSANDRA-10311:
------------------------------------------
Summary: AbstractType value compatibility checks are broken for some of the
implementations (was: It looks like our type alterations may be buggy)
> AbstractType value compatibility checks are broken for some of the
> implementations
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-10311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10311
> Project: Cassandra
> Issue Type: Bug
> Reporter: Benedict
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> 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)
