[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228247#comment-14228247
]
Sylvain Lebresne commented on CASSANDRA-7304:
---------------------------------------------
Remarks on the last patch:
* In the spec, instead of changing the meaning of {{\[bytes\]}}, I would rather
add a new {{\[value\]}} definition that support 'unset', and use that
exclusively in the definition of values for bind variables in QUERY and EXECUTE
messages, so as to make it clear that it makes no sense in any other place. I
would then add a specific {{CBUtil.readBoundValue()}} to read those.
* Making {{UNSET_CONSTANT_VALUE}} be {{new Value(null)}} is somewhat incorrect,
it should be {{new Value(UNSET_BYTE_BUFFER)}} so that we don't lose the the
information that it's 'unset' if {{bindAndGet}} is used. For this reason, I'd
prefer using {{Constants.UNSET_CONSTANT_VALUE}} (renamed as {{UNSET_VALUE}}) in
collections too (instead of adding {{Lists.UNSET_LIST_VALUE}}, ...).
* We can't have an 'unset' value inside a collection since we don't allow bind
markers in the first place, and so there is a bit of useless code/validation
related to that.
* There is a bunch of place that don't handle 'UNSET_BYTE_BUFFER' properly:
Tuples, ColumnCondition (we might want to reject queries for which all
conditions are 'unset' as going through the paxos code for no reason feels like
the user is doing something wrong) and SelectStatement where we could get an
'unset' pretty much anywhere where the {{values()}} or {{bound()}} method of a
{{Restriction}} is used (and validation might be tricky in SelectStatement: if
we have {{SELECT * FROM foo WHERE k1 = ? AND k2 = ? AND k3 = ?}}, then we
shouldn't accept an 'unset' for {{k2}} unless {{k3}} is also unset; note that
I'd be fine just refusing 'unset' in selects for now to simplify, but we at
least need the validation code to reject them).
* I'd reject 'unset' indexes in {{UDPATE ... SET l\[?\] = ?}} since it's
rejected for map keys. Unless maybe if both the key/index and value are
'unset', but that should be coherent for lists and maps.
* In Constants.Marker.bindAndGet, we should skip validation if 'unset' (even
though the validation will never fail because empty values are always accepted,
it's still dodgy).
* We should have separate error messages when we reject both {{null}} and
{{unset}}.
* I'd prefer rejecting 'unset' inside UDTs (and tuples). Making it equivalent
to {{null}} gives it a different meaning than usual and we should avoid that.
* For the limit in SelectStatement, it would make sense to accept unset and to
have it mean "no limit" (instead of being rejected). The same applies for the
timestamp and ttl in {{Attributes}}.
* In CBUtil.readValue(), we should throw a ProtocolException instead of an
IllegalArgumentException.
Also a couple of nitpicks:
* In ModificationStatement.executeInternal, the body of the {{for}} loop should
just be replaced by {{mutation.apply()}}.
* I might have put {{UNSET_BYTE_BUFFER}} in {{ByteBufferUtil}} since it's a
{{ByteBuffer}}.
* The patch appears to have windows end-of-line and a few weird indentations.
Could you check that?
* I'd have added an unset() in CQLTester to use in tests to make the tests
terser.
> 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
> Assignee: Oded Peer
> 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)
