[ 
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to