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