Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 44B3418442 for ; Sun, 13 Sep 2015 10:14:51 +0000 (UTC) Received: (qmail 56330 invoked by uid 500); 13 Sep 2015 10:14:45 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 56294 invoked by uid 500); 13 Sep 2015 10:14:45 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 56276 invoked by uid 99); 13 Sep 2015 10:14:45 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2015 10:14:45 +0000 Date: Sun, 13 Sep 2015 10:14:45 +0000 (UTC) From: "Benedict (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (CASSANDRA-10311) It looks like our type alterations may be buggy MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Benedict created CASSANDRA-10311: ------------------------------------ Summary: 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)