[jira] [Commented] (CASSANDRA-10311) AbstractType value compatibility checks are broken for some of the implementations

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ 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)