Return-Path: 
 <commits-return-54381-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 D48FAC3BF
	for <apmail-cassandra-commits-archive@www.apache.org>;
 Wed, 16 May 2012 08:00:51 +0000 (UTC)
Received: (qmail 98641 invoked by uid 500); 16 May 2012 08:00:51 -0000
Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org
Received: (qmail 97950 invoked by uid 500); 16 May 2012 08:00:47 -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 97886 invoked by uid 99); 16 May 2012 08:00:45 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 May 2012 08:00:45 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 May 2012 08:00:43 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id 0206A637F
	for <commits@cassandra.apache.org>; Wed, 16 May 2012 08:00:23 +0000 (UTC)
Date: Wed, 16 May 2012 08:00:23 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <48938814.3217.1337155223009.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1240609770.58691.1336852250489.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CASSANDRA-4242) Name of parameters should be
 available in CqlPreparedResult
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


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

Sylvain Lebresne commented on CASSANDRA-4242:
---------------------------------------------


I can see the point of returning the names in the CqlPreparedResult. However, despite Jonathan's suggestion, I actually prefered the original one (except for the binary->string), i.e.:
{noformat}
struct CqlPreparedResult {
     1: required i32 itemId,
     2: required i32 count,
     3: optional list<string> variable_types
+    4: optional list<string> variable_names
}
{noformat}

The reason is mainly that I don't see the point in breaking CQL3 clients. I agree CqlMetadata is overkill for CQL3, but imo CASSANDRA-2478 is where we should bother fixing this.

Also, the variable_types in CqlPreparedResult is actually not a CQL2 thing, but a CQL3 thing exclusively, so deprecating it in say 1.1.1 when it was introduced in 1.1.0 feels again a bit harsh on the client writers for no good reasons.

bq. I have the feeling that C* is moving away from sliced query on binary column names (a strong feature in my opinion)

It does not. The difference is that a column name *in CQL3* does not necessarily map to a internal column name. So CQL3 column names *are* strings and this without any loss of generality.

bq. Moreover, CqlMetadata exposes column names as binary

Yes, but that part is due to the difference between CQL2 and CQL3. Concretely, CQL3 will *never* return anything else than UTF8 bytes (which is why Jonathan suggested replacing CqlMetadata by a map<string, string> for CQL3, but see my argument above). In any case, given that the variable names will be CQL3 only (we cannot, even if we wanted to, do it in CQL2), I don't think there is a point in returning binary.

                
> Name of parameters should be available in CqlPreparedResult
> -----------------------------------------------------------
>
>                 Key: CASSANDRA-4242
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4242
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.0
>            Reporter: Pierre Chalamet
>            Priority: Minor
>         Attachments: 4242.txt, 4242_2.txt, 4242_3.txt
>
>
> Client side, it could be nice to have the name of parameters in CqlPreparedResult. This could allow parameters mapping by name instead of by index.
> {code}
> struct CqlNameType {
>     1: required binary key,
> 	2: required string type
> }
> struct CqlPreparedResult {
>     1: required i32 itemId,
>     2: required i32 count,
>     3: optional list<string> variable_types,
>     4: optional list<CqlNameType> name_types
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira