cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8374) Better support of null for UDF
Date Sun, 04 Jan 2015 11:05:35 GMT


Sylvain Lebresne commented on CASSANDRA-8374:

bq. I think you may be overlooking the option of doing something other than returning null
or raising an error when a null argument is passed.

I don't think I do. I said earlier:

bq. the overwhelming majority of functions have only 2 reasonable ways to handle null inputs:
either throw, or return null. There is certainly functions for which it makes sense to return
a non-null value on null inputs, but it's pretty rare.

to which you answered

bq. Agreed.

I'm not at all arguing that we shouldn't have the {{CALLED ON NULL INPUT}} option, we absolutely
should. I'm saying that functions that actually handle null in a meaningful way are very rare
(I would argue especially for database functions that are mainly "pure" mathematical functions)
and so they're not meaningful to picking our default. Further, I'm saying that when we'll
add an extended standard library of out of the box functions (which we'll almost surely do,
with at least basic math, string manipulation and date related functions), 99% percent of
those functions will return null on null inputs (because again, throwing instead means the
function can't be use in select clauses which is not an ok limitation), the 1% remaining being
of those rare functions that return some other value. If we disagree on that, then I'm curious
what your concrete plan for handling null in those functions would be, but if we agree, then
I think this is a pretty clear indication that this should be the default for UDF.

bq. As a summary - am I right that we

We haven't totally agreed yet on the default part. But that's otherwise a good summary of
what I personally think we should do.

> Better support of null for UDF
> ------------------------------
>                 Key: CASSANDRA-8374
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Robert Stupp
>             Fix For: 3.0
>         Attachments: 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
> {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

View raw message