cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-7395) Support for pure user-defined functions (UDF)
Date Fri, 01 Aug 2014 22:59:40 GMT


Tyler Hobbs commented on CASSANDRA-7395:

> Application level conflicts may arise if new 'core CQL' functions appear in a future
C* version with the same name of existing UDFs. We should make that clear in documentation
and encourage users to use namespaces. The only alternative that came to my mind was to force
users to use SELECT ::sin(foo)... for non-namespace UDFs - but I'm not happy with that alternative.

I think encouraging the use of namespaces is the best way to go.  Perhaps on startup we could
check for any non-namespaced UDFs that would be inaccessible due to a collision with a (new)
core function name and log a warning?  At that point, the user could define the function within
a namspace.

Comments on the patch:

* UFMetaData:

  * Bad javadoc for the class
  * Redundant work in constructors
  * compatibleArgs():

    * argType should not be null (no TypeAndData)
    * To fix the IRE case, make AssignementTestable.isAssignableTo() not throw an IRE,
      add validateAssignableTo() which does throw an IRE

  * parseCQLType(): want InvalidRequestException instead of ConfigurationException
  * dropFunction(): use ColumnFamily.delete() to remove the whole partition instead of individual

    * Do we need a way to drop a specific signature and not all versions of a function?

  * adding toString() would be nice, as it's expected by the logger in a couple of places
* MigrationManager:

  * Throw IRE instead of ConfigurationException (and update DropFunctionStatement)

* CFMetaData:

  * Use 604800 for gc_grace_seconds (see CASSANDRA-7668)

* FunctionCall:

  * prepare(): no need for curly braces on "if" with single statement
  * prepare(): s/Unknown CQL3 function called/Unknown function called/
  * toString(): no single-line if-statements, please
* Selectable:

  * toString(): no single-line if-statements

* DefsTables:

  * add/update/dropFunction() do need to notify listeners (you have TODOs there), so we need

* Event:

  * Keyspace string should be empty for UDF changes (we'll need a v4 protocol doc soon)
  * serializeEvent() and eventSerializedSize() will need to handle function events specially
when the protocolversion < 4.  I guess we shouldn't send events at all? I'm not too sure
about this one.
* CreateFunctionStatement:

  * constructor: Instead of throwing NPEs, use assertions
  * changeEvent(): whitespace is off 
  * execute(): throw IREs instead of ConfigurationExceptions

* DropFunctionStatement:

  * Unused imports

* UDFunction:

  * "throws" can go on the same line as method signature
  * Throw IRE instead of ConfigurationException
* UDFRegistry:
  * no need for curlies on single-statement "ifs" (there are a few)
  * refreshInitial():
    * use QueryProcess.executeOnceInternal() instead of process()
    * put for-loop initialization on single line
    * if we fail to query system.schema_functions, let the exception propagate

Overall, the patch is looking really good.  After the next round of fixes, I'll do some testing
and further review.

We also definitely want to get good test coverage of this.  Unit tests that extend CQLTester
would be a good start (and they could use functions from the test class for UDFs).

> Support for pure user-defined functions (UDF)
> ---------------------------------------------
>                 Key: CASSANDRA-7395
>                 URL:
>             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.

This message was sent by Atlassian JIRA

View raw message