cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8354) A better story for dealing with empty values
Date Wed, 26 Nov 2014 06:25:14 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225824#comment-14225824
] 

Jonathan Ellis commented on CASSANDRA-8354:
-------------------------------------------

bq. "ALLOW EMPTY" (or whatever equivalent syntax) could be useful for types like strings or
blob when you know an empty string/blob doesn't make sense and you want the database to validate
it

This is too specific a use case to warrant special syntax.  We can certainly add CHECK constraints
using UDF though.

> 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)

Mime
View raw message