[
https://issues.apache.org/jira/browse/CASSANDRA-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142995#comment-15142995
]
Aleksey Yeschenko commented on CASSANDRA-10311:
-----------------------------------------------
bq. Mind being more precise? What it currently allows is to change from a int
or bigint to a varint, which seems ok to me since any int or bigint is a valid
binary representation for the equivalent varint. We don't allow the reverse
conversion in particular.
You are correct. While something else might be broken, this in particular is
not. And nothing else really jumped out at me either. This ticket can be closed.
> 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)
