cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10783) Allow literal value as parameter of UDF & UDA
Date Fri, 10 Jun 2016 20:08:21 GMT

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

Sylvain Lebresne commented on CASSANDRA-10783:
----------------------------------------------

bq. The fact that {{Term.Raw}} implements {{Selectable}} looks confusing to me from a hierachy
point of view.

Can't say I understand why that's confusing, and that slightly simplified the code, but I
don't really mind the alternative so made that change.

bq. The fact that {{ColumnIdentifier.Raw::prepare}} produce a {{ColumnDefinition}} does not
look really logical. I would be in favor of moving {{ColumnIdentifier::Raw}} and its implementations
to {{ColumnDefinition}}.

Here again, not convinced one is a lot more logical than the other, but I'm fine moving to
{{ColumnDefinition}}. The commit is bigish but that's mostly renamings (since {{ColumnIdentifier.Raw}}
was used in quite a few places).

bq. In {{WithFieldSelection}} switching from {{ColumnIdentifier}} to {{ByteBuffer}} makes
the column name unreadable in the error message.

Good point. I actually decided to introduce a {{FieldIdentifier}} class instead of using {{ByteBuffer}}
directly. I think it's cleaner and safer. Other slightly big commit but mostly trivial.

{quote}
* {{UnrecognizedEntityException}} is not used anymore and can be remove as well as the try-catch
block in {{SelectStatement::prepareRestrictions}} and the containsAlias method.
* {{Relation::toColumnDefinition}} could be inlined
* {{SelectorFactories::asList}} is not used and could be removed
* {{Selector}} contains some unused imports
{quote}

Removed.

{quote}
* in testSelectPrepared:
{noformat}
execute("SELECT pk, ck, " + fIntMax + "(i, (int)?) FROM %s WHERE pk = " + fIntMax + "((int)1,(int)1)",
unset())
{noformat}
{quote}

Did you meant something else? As far as I can tell that's the exact same line that your other
comment.

Updated patches and tests results (same place as above):
|| [trunk|https://github.com/pcmanus/cassandra/commits/10783] || [utests|http://cassci.datastax.com/job/pcmanus-10783-testall/]
|| [dtests|http://cassci.datastax.com/job/pcmanus-10783-dtest/] ||


> Allow literal value as parameter of UDF & UDA
> ---------------------------------------------
>
>                 Key: CASSANDRA-10783
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10783
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: DOAN DuyHai
>            Assignee: Robert Stupp
>            Priority: Minor
>              Labels: CQL3, UDF, client-impacting, doc-impacting
>             Fix For: 3.x
>
>
> I have defined the following UDF
> {code:sql}
> CREATE OR REPLACE FUNCTION  maxOf(current int, testValue int) RETURNS NULL ON NULL INPUT

> RETURNS int 
> LANGUAGE java 
> AS  'return Math.max(current,testValue);'
> CREATE TABLE maxValue(id int primary key, val int);
> INSERT INTO maxValue(id, val) VALUES(1, 100);
> SELECT maxOf(val, 101) FROM maxValue WHERE id=1;
> {code}
> I got the following error message:
> {code}
> SyntaxException: <ErrorMessage code=2000 [Syntax error in CQL query] message="line
1:19 no viable alternative at input '101' (SELECT maxOf(val1, [101]...)">
> {code}
>  It would be nice to allow literal value as parameter of UDF and UDA too.
>  I was thinking about an use-case for an UDA groupBy() function where the end user can
*inject* at runtime a literal value to select which aggregation he want to display, something
similar to GROUP BY ... HAVING <filter clause>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message