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