[ https://issues.apache.org/jira/browse/CASSANDRA-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Holmberg updated CASSANDRA-9219: ------------------------------------- Labels: client-impacting (was: ) > 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: 3.0 > > > 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)