[ https://issues.apache.org/jira/browse/CASSANDRA-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165084#comment-14165084 ]
Jonathan Ellis commented on CASSANDRA-8063: ------------------------------------------- +1 > 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 > 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)