Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 14 May 2015 20:37:00 +0000 (UTC)
From: "Joshua McKenzie (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12822676.1429624220000.117727.1431635820586@Atlassian.JIRA>
In-Reply-To: <JIRA.12822676.1429624220000@Atlassian.JIRA>
References: <JIRA.12822676.1429624220000@Atlassian.JIRA>
 <JIRA.12822676.1429624220158@arcas>
Subject: [jira] [Reopened] (CASSANDRA-9219) Follow-ups to 7523: protect old
 clients from new type values and reject empty ByteBuffer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua McKenzie reopened CASSANDRA-9219:
----------------------------------------

> Follow-ups to 7523: protect old clients from new type values and reject empty ByteBuffer
> ----------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9219
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9219
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Joshua McKenzie
>            Assignee: Joshua McKenzie
>            Priority: Minor
>              Labels: client-impacting
>             Fix For: 2.2 beta 1
>
>         Attachments: 9219-nits.txt
>
>
> 2 follow-ups from CASSANDRA-7523, which has now been removed from the 2.1 branch:
> bq. The problem is that if someone use one of those new data types with an existing client, Cassandra will currently happily return the new codes, which clients have no reason to know about and may therefore crash in unexpected ways. That is a problem and that's what I meant by "Adding new codes to v3 would confuse drivers".
> bq. So what I mean is that we should special case those 2 types in DataType (maybe in toType, maybe directly in the serialization) so that when the protocol version is <= 3, then it write the types as CUSTOM ones. 
> And
> bq. can we make the new types non-emptiable by default? See the last two CASSANDRA-8951 comments.
> bq. Would really like us to reject empty BB as a valid value there though


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)