Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 24 Jun 2014 11:25:25 +0000 (UTC)
From: "Robert Stupp (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12720964.1402602576786.36458.1403609125168@arcas>
In-Reply-To: <JIRA.12720964.1402602576786@arcas>
References: <JIRA.12720964.1402602576786@arcas>
Subject: [jira] [Comment Edited] (CASSANDRA-7395) Support for pure
 user-defined functions (UDF)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041923#comment-14041923 ] 

Robert Stupp edited comment on CASSANDRA-7395 at 6/24/14 11:23 AM:
-------------------------------------------------------------------

bq. Let's not over-think it at first

just had that idea and want to keep it in mind


I currently have some "spec" for UDF declaration in mind which is not directly related to {{Function}} interface. 

A "UDF class scanner" collects all classes annotated with {{@UDFBundle}} and all methods annotated with {{@UDF}}. 
Methods' return types and parameter types are mapped to CQL types. Ambigious types (like UUID) can be specialized using an annotation parameter but have a default mapping (e.g. UUID = timeuuid, String = text).
Primitive Java types would be only allowed as return types. UDF method parameter types must use the "object" variant to allow {{null}} handling.
Means: (de)serialization is done outside of the UDF implementation if not explicitly requested.
This shall keep the UDF implementation itself "simple" without the need to explicitly build (de)serialization code - which may lead to a lot of copy-and-paste code in UDFs making them unnecessarily big.

{noformat}
@UDFBundle(name = "foobar")
public class MyUDFs {
    @UDF(
        name = "sin",
        deterministic = true      // flag which can be used later for "function based indexes"
    )
    public Double sinForDouble(Double input) {
        return input == null ? null : Math.sin(input);
    }
    @UDF(name = "sin", deterministic=true)
    public Float sinForFloat(Float input) {
        return input == null ? null : Math.sin(input);
    }

    @UDF(
        deterministic = true,
        paramTypes = { "timeuuid" }
    )
    public Date timeuuidToDate(UUID uuid) { ... }

    @UDF(
        deterministic = true,
        paramTypes = { "text" }
    )
    public Integer some(ByteBuffer blob)    // gets "raw" data

    @UDF(
        deterministic = true,
        paramTypes = { "list<timeuuid>" }
    )
    public List<Date> timeuuidToDate(List<UUID> uuid) { ... }

    @UDF(
        name = "mysuperhash",
        deterministic = true
    )
// a UDF that can handle any data type
    public Long someSpecialHashFunctionThatTakesAnyDataType( org.apache.cassandra.udf.TypeAndData anyType ) {
        AbstractType type = any.getType();
        ByteBuffer value = any.getValue();
    }
}
{noformat}

Is this something worth to discuss?


was (Author: snazy):
bq. Let's not over-think it at first

just have that idea and keep it in mind


I currently have some "spec" for UDF declaration in mind which is not directly related to {{Function}} interface. 

A "UDF class scanner" collects all classes annotated with {{@UDFBundle}} and all methods annotated with {{@UDF}}. 
Methods' return types and parameter types are mapped to CQL types. Ambigious types (like UUID) can be specialized using an annotation parameter but have a default mapping (e.g. UUID = timeuuid, String = text).
Primitive Java types would be only allowed as return types. UDF method parameter types must use the "object" variant to allow {{null}} handling.
Means: (de)serialization is done outside of the UDF implementation if not explicitly requested.
This shall keep the UDF implementation itself "simple" without the need to explicitly build (de)serialization code - which may lead to a lot of copy-and-paste code in UDFs making them unnecessarily big.

{noformat}
@UDFBundle(name = "foobar")
public class MyUDFs {
    @UDF(
        name = "sin",
        deterministic = true      // flag which can be used later for "function based indexes"
    )
    public Double sinForDouble(Double input) {
        return input == null ? null : Math.sin(input);
    }
    @UDF(name = "sin", deterministic=true)
    public Float sinForFloat(Float input) {
        return input == null ? null : Math.sin(input);
    }

    @UDF(
        deterministic = true,
        paramTypes = { "timeuuid" }
    )
    public Date timeuuidToDate(UUID uuid) { ... }

    @UDF(
        deterministic = true,
        paramTypes = { "text" }
    )
    public Integer some(ByteBuffer blob)    // gets "raw" data

    @UDF(
        deterministic = true,
        paramTypes = { "list<timeuuid>" }
    )
    public List<Date> timeuuidToDate(List<UUID> uuid) { ... }

    @UDF(
        name = "mysuperhash",
        deterministic = true
    )
// a UDF that can handle any data type
    public Long someSpecialHashFunctionThatTakesAnyDataType( org.apache.cassandra.udf.TypeAndData anyType ) {
        AbstractType type = any.getType();
        ByteBuffer value = any.getValue();
    }
}
{noformat}

Is this something worth to discuss?

> 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
>             Fix For: 3.0
>
>         Attachments: 7395.diff
>
>
> 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)