[
https://issues.apache.org/jira/browse/CASSANDRA-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383844#comment-14383844
]
Sylvain Lebresne commented on CASSANDRA-8374:
---------------------------------------------
So, I think it's time to decide where we go here. As I said in my previous
comment, my preference here is to go with no default and an explicit choice.
And doing so still leaves the ability to change our mind later and add a
default, so I suggest we implement that and if someone feels strongly about a
particular default, he can open a follow up ticket.
[~snazy] can you rebase your branch, make sure it implements what's above and
remind us where that branch actually is?
> Better support of null for UDF
> ------------------------------
>
> Key: CASSANDRA-8374
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8374
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Robert Stupp
> Labels: client-impacting, cql3.3, docs-impacting, udf
> Fix For: 3.0
>
> Attachments: 8374-3.txt, 8473-1.txt, 8473-2.txt
>
>
> Currently, every function needs to deal with it's argument potentially being
> {{null}}. There is very many case where that's just annoying, users should be
> able to define a function like:
> {noformat}
> CREATE FUNCTION addTwo(val int) RETURNS int LANGUAGE JAVA AS 'return val + 2;'
> {noformat}
> without having this crashing as soon as a column it's applied to doesn't a
> value for some rows (I'll note that this definition apparently cannot be
> compiled currently, which should be looked into).
> In fact, I think that by default methods shouldn't have to care about
> {{null}} values: if the value is {{null}}, we should not call the method at
> all and return {{null}}. There is still methods that may explicitely want to
> handle {{null}} (to return a default value for instance), so maybe we can add
> an {{ALLOW NULLS}} to the creation syntax.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
