[
https://issues.apache.org/jira/browse/CASSANDRA-8354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223462#comment-14223462
]
Jonathan Ellis commented on CASSANDRA-8354:
-------------------------------------------
Is there a way we can avoid permanently enshrining this wart?
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.
> 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)
