cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oded Peer (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements
Date Thu, 11 Dec 2014 20:10:15 GMT

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

Oded Peer updated CASSANDRA-7304:
---------------------------------
    Attachment: 7304-04.patch

I appreciate your comments, they are very helpful and I am learning a lot from them.
bq. 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.
Done
bq. 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}},
...).
Done
bq. 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.
I verified the changes aren’t useless with unit tests.
bq. 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 opted for rejecting unset values in selects. It’s not only to simplify I think it’s
the right thing to do. Having a variable assignment or a condition with unset variables is
undefined.
bq. 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.
Done
bq. 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).
Done
bq. We should have separate error messages when we reject both {{null}} and {{unset}}.
Done
bq. 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.
Done
bq. 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}}.
Done
bq. In CBUtil.readValue(), we should throw a ProtocolException instead of an IllegalArgumentException.
Done
bq. I might have put {{UNSET_BYTE_BUFFER}} in {{ByteBufferUtil}} since it's a {{ByteBuffer}}.
Done
bq. The patch appears to have windows end-of-line and a few weird indentations. Could you
check that?
My apologies. I switched to Ubuntu.
bq. I'd have added an unset() in CQLTester to use in tests to make the tests terser.
Done



> 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-04.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)

Mime
View raw message