[
https://issues.apache.org/jira/browse/CASSANDRA-8354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225968#comment-14225968
]
Sylvain Lebresne commented on CASSANDRA-8354:
---------------------------------------------
Thing is, I'm not sure how we could properly convert people out of those empty
values completely without breaking thrift compatibility.
I'm typically not sure how that {{strict_cql_values}} option would work in
practice (would that be a global yaml option that affects thrift too btw?).
That said, I've kind of mixed two issues in this ticket. The main reason I've
opened this was the UDF question, but I realize that this question is actually
already a problem with {{null}} and so I've created a separate issue for it
(CASSANDRA-8374). Provided we fix that latter issue, it's probably ok for UDT
to consider that empty values (for types for which they are not reasonable
values) are always converted to {{null}} (which is already how it works in
fact).
Still, it would be nice to change the default for CQL so that empty values are
refused. I'm just not sure I see how to make that happen in practice without a
syntax addition.
> 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)
