[
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083931#comment-14083931
]
Robert Stupp commented on CASSANDRA-7395:
-----------------------------------------
Thanks [~thobbs] :)
I've fixed that stuff. Some notes:
* SchemaChange events from {{Create/DropFunctionStatement}}: I’m also not
really sold on sending events for UDF to clients - just did that for
„completeness“. Even though it is not a schema change in the meaning that a
keyspace (persistence) is involved. It is more a new type of change event. If
someone wants those events to be delivered we can do that later in a separate
ticket. But the {{MigrationManager.notity}} methods also use Event. I’ve added
new {{Event.FunctionChange}} class and removed the UDF code from
{{Event.SchemaChange}}.
* UFMetaData/constructors: Yes, it's duplicate work - but difficult to change.
The ctors differ in argument/return type ({{CQL3Type}}/{{String}}). I tried to
combine the code but it looks even uglier (3rd ctor, additional static methods).
* UFMetaData/compatibleArgs: I'd like to defer the change to a separate commit
because it touches a lot of files. But I'm +1 to do that.
* Added a warning log on startup when a non-namespaced UDF with the same name
of a core-CQL-function is found (w/ hint to do a {{DESCRIBE FUNCTION}} before
{{DROP FUNCTION}}).
Current todos:
* build a UDF impl jar (or "Cassandra stdlib" ;) - stuff for separate ticket)
* build some "plain" unit tests
* build dtest(s)
> Support for pure user-defined functions (UDF)
> ---------------------------------------------
>
> Key: CASSANDRA-7395
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7395
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Assignee: Robert Stupp
> Labels: cql
> Fix For: 3.0
>
> Attachments: 7395.txt, udf-create-syntax.png, udf-drop-syntax.png
>
>
> We have some tickets for various aspects of UDF (CASSANDRA-4914,
> CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of
> ocean-boiling.
> Let's start with something simple: allowing pure user-defined functions in
> the SELECT clause of a CQL query. That's it.
> By "pure" I mean, must depend only on the input parameters. No side effects.
> No exposure to C* internals. Column values in, result out.
> http://en.wikipedia.org/wiki/Pure_function
--
This message was sent by Atlassian JIRA
(v6.2#6252)
