Return-Path: 
 <commits-return-146328-apmail-cassandra-commits-archive=cassandra.apache.org@cassandra.apache.org>
X-Original-To: apmail-cassandra-commits-archive@www.apache.org
Delivered-To: apmail-cassandra-commits-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 3D916175CC
	for <apmail-cassandra-commits-archive@www.apache.org>;
 Fri, 18 Sep 2015 10:40:05 +0000 (UTC)
Received: (qmail 46376 invoked by uid 500); 18 Sep 2015 10:40:05 -0000
Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org
Received: (qmail 46334 invoked by uid 500); 18 Sep 2015 10:40:05 -0000
Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@cassandra.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@cassandra.apache.org>
List-Post: <mailto:commits@cassandra.apache.org>
List-Id: <commits.cassandra.apache.org>
Reply-To: dev@cassandra.apache.org
Delivered-To: mailing list commits@cassandra.apache.org
Received: (qmail 46321 invoked by uid 99); 18 Sep 2015 10:40:05 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Sep 2015 10:40:05 +0000
Date: Fri, 18 Sep 2015 10:40:04 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12875661.1442517531000.10760.1442572804973@Atlassian.JIRA>
In-Reply-To: <JIRA.12875661.1442517531000@Atlassian.JIRA>
References: <JIRA.12875661.1442517531000@Atlassian.JIRA>
 <JIRA.12875661.1442517531812@arcas>
Subject: [jira] [Commented] (CASSANDRA-10367) Aggregate with Initial
 Condition fails with C* 3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


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

Sylvain Lebresne commented on CASSANDRA-10367:
----------------------------------------------

So yeah, it sounds pretty clear to me that the main problem is CASSANDRA-9613. We shouldn't have to re-serialize the state every time and so this shouldn't matter.

So I say, let's copy the collection for now (I honestly doubt anyone will see any measurable difference in practice) and let CASSANDRA-9613 optimize the inefficiency.

bq. I'm still unsure if returning an unmodifiable collection is a good idea in the driver

I disagree but that's a decision for the driver. There is no point in forcing the driver to change their code when copying the collection is really not a big deal and we know we'll optimize it out soon enough.

> 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.x
>
>
> 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)