[jira] [Comment Edited] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938062#comment-13938062
]
Edward Capriolo edited comment on CASSANDRA-6871 at 3/17/14 5:17 PM:
-
{quote}
It sounds like I'd still be shipping jars around
{quote}
No. You have the option of placing the payload of the trigger in the script
field if the spec supports it. However the old way will work as well.
was (Author: appodictic):
{quote}
It sounds like I'd still be shipping jars around
{quote}
No. You have the option of placing the payload of the UDF in the script field
if the spec supports it. However the old way will work as well.
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CASSANDRA-6871) Dynamic class loading for triggers (and udfs)
[
https://issues.apache.org/jira/browse/CASSANDRA-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938062#comment-13938062
]
Edward Capriolo edited comment on CASSANDRA-6871 at 3/17/14 5:16 PM:
-
{quote}
It sounds like I'd still be shipping jars around
{quote}
No. You have the option of placing the payload of the UDF in the script field
if the spec supports it. However the old way will work as well.
was (Author: appodictic):
{quote}
It sounds like I'd still be shipping jars around
{quote}
You have the option of placing the payload of the UDF in the script field if
the spec supports its.
> Dynamic class loading for triggers (and udfs)
> -
>
> Key: CASSANDRA-6871
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6871
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Edward Capriolo
>Assignee: Edward Capriolo
>
> Currently the trigger feature requires out of band shipping jar files to
> servers. In the near future users may be able to provide custom functions
> like trim() dynamically like pig and hive do. In order to accomplish this
> securely my suggestion is this.
> 1. Add a new configuration knob to cassandra.yaml which controls how users
> are allowed to load class definitions.
> {code}
> dynamic_loading:
> - JAVA_LOCAL_CLASSPATH
> - GROOVY_CLASS_LOADER
> {code}
> 2. Add the https://github.com/edwardcapriolo/nit-compiler to the project as a
> dependency.
> 3. Profit: A follow on piece would allow triggers to be defined in a JVM
> language. Features like https://issues.apache.org/jira/browse/CASSANDRA-6870
> could use this. Users can also create different pluggable components to CQL
> at runtime.
> This issue would just be about brining the dynamic loading mechanism in the
> project securely. Not implementing it in a user facincg way.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
