[
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14055953#comment-14055953
]
Robert Stupp commented on CASSANDRA-7395:
-----------------------------------------
[~thobbs] Thanks for taking a look. :)
bq. I prefer to start with a more general and powerful solution and work on
friendliness later. This means ByteBuffers get passed in.
I'd propose a solution that supports both - plain, simple types and "every"
type.
* Plain, simple types like {{int32}}, {{timestamp}}, etc with "built-in"
conversion allows function overloading - these functions could be annotated
with {{@UDF}}.
* Other, complex data types like {{list<foo<bar>>}} or UDTs could be passed
directly to the function implementation by something like a "generic"
{{@GenericUDF}} which gets a {{TypeAndData}} for each parameter or even a
{{List<TypeAndData>}} (or array).
This would allow to write UDFs that implement {{Math.sin}} for all types (int,
long, float, double, BigInteger, BigDecimal) in a straightforward manner and
handle complex types if the user wants to. Maybe it would be nice to give the
user some utility functions to deal with "complex" types or to do fancy things
like the {{collectionLength()}} example you mentioned. But - as you said - this
is debatable :)
bq. stick with the simpler approach of dropping jars in a directory
Yes - I didn't had the implications of a "1000 node cluster" in mind. Means:
1000 nodes would ask all other nodes regularly for new UDFs. That could
generate some traffic and load...
Proposal: just let the user drop UDF jars into a "special" directory. Changes
in that directory are scanned by a background task (without the need to
explicitly execute a JMX operation) - but there's an argument against "dropping
jars" below.
bq. dealing with existing prepared statements when a UDF changes
You didn't miss it - I hadn't that in mind.
But I think that (maybe I'm wrong) existing prepared statements do not need to
be invalidated, if the UDF is coded with it's exact signature (e.g. {{public
double sin(double val))} and the function is deterministic.
But pstmts need to be invalidated if they are coded with a "wildcard" signature
like {{public ByteBuffer sin(TypeAndData value)}}.
The distinction would be easy if we use {{@UDF}} and {{@GenericUDF}}.
(off topic but related:) More important is that functional indexes might need
be rebuilt or at least invalidated if a UDF used by a functional index changes.
Although "functional indexes" are not built in yet, it's worth to keep that
feature in mind. Such a situation might be easier to handle with some "UDF
deployment tool" (it it writes to a keyspace or not). Or all nodes mark the
affected functional index as invalid and just log warnings.
bq. I personally like the bundle/namespace approach, and I think the
annotations are a quite nice
:)
> 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
> Labels: cql
> Fix For: 3.0
>
> Attachments: 7395-v2.diff, 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)
