cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Olivier Michallat (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10367) Aggregate with Initial Condition fails with C* 3.0
Date Wed, 07 Oct 2015 15:47:27 GMT

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

Olivier Michallat commented on CASSANDRA-10367:
-----------------------------------------------

Can't 9613 be reprioritized for 3.0.x?

Fixing this on the driver side forces us to expose an overkill API ("codec factory" as suggested
by Robert) that is unlikely to ever be useful elsewhere. That's particularly overkill if it's
just a temporary fix for something that will eventually get solved in another Cassandra ticket.

A corollary to this question is, do you plan to backport 9613 to the 2.2 branch? Since recent
versions of the 2.2 driver will also exhibit the issue.

> Aggregate with Initial Condition fails with C* 3.0
> --------------------------------------------------
>
>                 Key: CASSANDRA-10367
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10367
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 3.0 branch
> https://github.com/apache/cassandra/tree/cassandra-3.0
>            Reporter: Greg Bestland
>            Assignee: Robert Stupp
>             Fix For: 3.0.0 rc2
>
>
> I'm seeing some inconsistent behavior between  2.2 and 3.0 C* with regards to UDF, Aggregates
and Initial Conditions. I have a scenario, which I think is valid. It works in C* 2.2 but
not in 3.0
> Using the following user defined function
> {code:sql}
> CREATE OR REPLACE FUNCTION extend_list(s list<text>, i int)
>                                   CALLED ON NULL INPUT
>                                   RETURNS list<text>
>                                   LANGUAGE java AS 'if (i != null) s.add(String.valueOf(i));
return s;';
> {code}
> With the aggregate below
> {code:sql}
> CREATE AGGREGATE aggregatemetadata.test_init_cond_aggregate(int) SFUNC extend_list STYPE
list<text> INITCOND [  ]
> {code}
> When I attempt to exercise the aggregate on from a simple key value table.
> {code:sql}
> SELECT test_init_cond_aggregate(v) AS list_res FROM t
> {code}
> in 2.2 it works fine and returns the aggregate.
> The exact same test ran against the 3.0 branch produces the following exception from
the server.
> {code:java}
> InvalidRequest: code=2200 [Invalid query] message="ERROR FUNCTION_FAILURE: execution
of 'aggregatemetadata.extend_list[list<text>, int]' failed: java.lang.UnsupportedOperationException"
> {code}
> I've grepped through the C* logs but I couldn't find a more verbose stack trace, or any
errors. 
> Robert Stupp suggested I open a ticket.
> I am able to reproduce both in the python driver manually using cql.



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

Mime
View raw message