[
https://issues.apache.org/jira/browse/CASSANDRA-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp reassigned CASSANDRA-8063:
---------------------------------------
Assignee: Robert Stupp
> Consider removing UDF-as-class functionality
> --------------------------------------------
>
> Key: CASSANDRA-8063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8063
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sylvain Lebresne
> Assignee: Robert Stupp
> Labels: cql
> Fix For: 3.0
>
>
> We've introduce 2 ways to provide (scalar) UDFs: either by providing a
> class+method name (and assuming C* can find such class and method in the
> classpath), or by providing the body of the function directly in the {{CREATE
> FUNCTION}} statement (with such body being able to be in either java or some
> variety of scripting languages).
> I submit that we remove the first option: the declaration of functions from a
> class+method name. I was the first to insist on adding it, but in hindsight I
> think it adds more complexity/confusion than anything else. More
> specifically, I think the UDF-as-class option is always inferior to
> CASSANDRA-7562 because:
> # it's more error prone. You have to manually deploy the class containing the
> function to every C* node (and make sure it is in the classpath). It's way
> too easy to end up with some node not having the function due to simple
> operator error.
> # it's not faster. In fact, post-CASSANDRA-7924, the UDF-as-java-source is
> probably faster since it doesn't involve reflection while the UDF-as-class
> option does.
> Overall, I think removing the UDF-as-class will simplify things without
> really losing anything (of course, we can re-evaluate this in the future if
> new arguments arises, but it's easier to add than to remove).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
