[ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oded Peer updated CASSANDRA-7304: --------------------------------- Attachment: 7304-03.patch 7304-03.patch contents: * Updated the v4 spec doc * Handled backward compatilbilty in {{CBUtil.readValue}} by inspecting the version protocol * Reverted modifications to CQLTester * Handled collections and counters * Since a UDT value is always written in its entirety Cassandra can't preserve a pre-existing value by 'not setting' the new value. unset values in UDT are treated as null values. * Added tests for collections and counters and UDT > Ability to distinguish between NULL and UNSET values in Prepared Statements > --------------------------------------------------------------------------- > > Key: CASSANDRA-7304 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7304 > Project: Cassandra > Issue Type: Sub-task > Reporter: Drew Kutcharian > Labels: cql, protocolv4 > Fix For: 3.0 > > Attachments: 7304-03.patch, 7304-2.patch, 7304.patch > > > Currently Cassandra inserts tombstones when a value of a column is bound to > NULL in a prepared statement. At higher insert rates managing all these > tombstones becomes an unnecessary overhead. This limits the usefulness of the > prepared statements since developers have to either create multiple prepared > statements (each with a different combination of column names, which at times > is just unfeasible because of the sheer number of possible combinations) or > fall back to using regular (non-prepared) statements. > This JIRA is here to explore the possibility of either: > A. Have a flag on prepared statements that once set, tells Cassandra to > ignore null columns > or > B. Have an "UNSET" value which makes Cassandra skip the null columns and not > tombstone them > Basically, in the context of a prepared statement, a null value means delete, > but we don’t have anything that means "ignore" (besides creating a new > prepared statement without the ignored column). > Please refer to the original conversation on DataStax Java Driver mailing > list for more background: > https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion -- This message was sent by Atlassian JIRA (v6.3.4#6332)