cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-8063) Consider removing UDF-as-class functionality
Date Mon, 06 Oct 2014 12:22:34 GMT


Sylvain Lebresne updated CASSANDRA-8063:
    Labels: cql  (was: )

> Consider removing UDF-as-class functionality
> --------------------------------------------
>                 Key: CASSANDRA-8063
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>              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

View raw message