[
https://issues.apache.org/jira/browse/CASSANDRA-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130261#comment-15130261
]
Sylvain Lebresne commented on CASSANDRA-10311:
----------------------------------------------
bq. At least {{IntegerType::isValueCompatibleWithInternal}} is certainly broken
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.
It's certainly true that {{SimpleDateType.isValueCompatibleWithInternal}} was
broken, but that makes this a duplicate of CASSANDRA-10027. I did a quick
survey of {{isValueCompatibleWithInternal}} and {{isCompatibleWith}} overrides
and nothing jumped out as broken, so unless I'm missing something on
{{IntegerType}}, I suggest closing as duplicate of CASSANDRA-10027?
bq. I assume it is deprecated, but there are no comments about it
Yes, it is deprecated and does deserve a comment. I ninja committed one.
bq. We should document how type coercion works
We don't coerce type implicitly, but I agree we should document the (explicit)
conversions allowed (for {{ALTER TABLE}} and type casts). I've created
CASSANDRA-11114 for that. It's probably fairly minor though since it's pretty
simple to find out which ones work or not through experimentation, and I expect
it to be relatively intuitive in most cases.
> 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)
