cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7395) Support for pure user-defined functions (UDF)
Date Tue, 24 Jun 2014 11:25:25 GMT

    [ 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)

Mime
View raw message