[
https://issues.apache.org/jira/browse/CASSANDRA-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-8374:
------------------------------------
Attachment: 8374-5.txt
Thanks for the review.
Changed the code according to your comments and proposals and pushed updates to
the branch.
bq. I do not understand the reason why we cannot replace a function with
{{RETURNS NULL ON NULL INPUT}} by the same one with {{CALLED ON NULL INPUT}}.
What if the user made a mistake and want to correct it.
The reason is basically that the function is referenced by a UDA. Changing the
{{CALLED ON/RETURNS NULL ON NULL INPUT}} status may make the UDA invalid (i.e.
{{INITCOND}} is required for {{RETURNS NULL ON NULL INPUT}}).
bq. In CQL.textile some of the markups do not render correctly
I don't see what you mean. I'm using https://borgar.github.io/textile-js/ to
check the output. Is it an issue with {{CQL.css}}? But updated CREATE/DROP
FUNCTION/AGGREGATE syntax definitions (all function/aggregate-name declarations
were accidentally optional).
> Better support of null for UDF
> ------------------------------
>
> Key: CASSANDRA-8374
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8374
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Robert Stupp
> Labels: client-impacting, cql3.3, docs-impacting, udf
> Fix For: 2.2.x
>
> Attachments: 8374-3.txt, 8374-3.txt, 8374-5.txt, 8473-1.txt,
> 8473-2.txt, 8473-4.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)
