[jira] [Updated] (CASSANDRA-8354) A better story for dealing with empty values

["C. Scott Andreas (JIRA)" <ji...@apache.org>]

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

C. Scott Andreas updated CASSANDRA-8354:
----------------------------------------
    Component/s: CQL

> 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
>          Components: CQL
>            Reporter: Sylvain Lebresne
>            Priority: Major
>             Fix For: 4.x
>
>
> 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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org