[
https://issues.apache.org/jira/browse/CASSANDRA-8354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223472#comment-14223472
]
Aleksey Yeschenko commented on CASSANDRA-8354:
----------------------------------------------
bq. What if for instance we added an option strict_cql_values to 3.0 that
defaults to false. When enabled it rejects nonsensical empty values. For 3.1 we
default to true, and give people a tool to convert empty to null or some other
value. For 4.0 it stays permanently true.
That. Except it's not just CQL, there is thrift too, where we should enforce
this, so maybe should name it 'reject_empty_types' or something. As a tool,
upgradesstables will probably do.
Don't want to legitimize it on CQL syntax level either.
> A better story for dealing with empty values
> --------------------------------------------
>
> Key: CASSANDRA-8354
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8354
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Fix For: 3.0
>
>
> In CQL, a value of any type can be "empty", even for types for which such
> values doesn't make any sense (int, uuid, ...). Note that it's different from
> having no value (i.e. a {{null}}). This is due to historical reasons, and we
> can't entirely disallow it for backward compatibility, but it's pretty
> painful when working with CQL since you always need to be defensive about
> such largely non-sensical values.
> This is particularly annoying with UDF: those empty values are represented as
> {{null}} for UDF and that plays weirdly with UDF that use unboxed native
> types.
> So I would suggest that we introduce variations of the types that don't
> accept empty byte buffers for those type for which it's not a particularly
> sensible value.
> Ideally we'd use those variant by default, that is:
> {noformat}
> CREATE TABLE foo (k text PRIMARY, v int)
> {noformat}
> would not accept empty values for {{v}}. But
> {noformat}
> CREATE TABLE foo (k text PRIMARY, v int ALLOW EMPTY)
> {noformat}
> would.
> Similarly, for UDF, a function like:
> {noformat}
> CREATE FUNCTION incr(v int) RETURNS int LANGUAGE JAVA AS 'return v + 1';
> {noformat}
> would be guaranteed it can only be applied where no empty values are allowed.
> A
> function that wants to handle empty values could be created with:
> {noformat}
> CREATE FUNCTION incr(v int ALLOW EMPTY) RETURNS int ALLOW EMPTY LANGUAGE JAVA
> AS 'return (v == null) ? null : v + 1';
> {noformat}
> Of course, doing that has the problem of backward compatibility. One option
> could be to say that if a type doesn't accept empties, but we do have an
> empty internally, then we convert it to some reasonably sensible default
> value (0 for numeric values, the smallest possible uuid for uuids, etc...).
> This way, we could allow convesion of types to and from 'ALLOW EMPTY'. And
> maybe we'd say that existing compact tables gets the 'ALLOW EMPTY' flag for
> their types by default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
