Return-Path: 
 <dev-return-8302-apmail-cassandra-dev-archive=cassandra.apache.org@cassandra.apache.org>
X-Original-To: apmail-cassandra-dev-archive@www.apache.org
Delivered-To: apmail-cassandra-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 05E3310428
	for <apmail-cassandra-dev-archive@www.apache.org>;
 Thu, 15 Aug 2013 17:02:57 +0000 (UTC)
Received: (qmail 57665 invoked by uid 500); 15 Aug 2013 17:02:11 -0000
Delivered-To: apmail-cassandra-dev-archive@cassandra.apache.org
Received: (qmail 57023 invoked by uid 500); 15 Aug 2013 17:01:52 -0000
Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cassandra.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cassandra.apache.org>
List-Post: <mailto:dev@cassandra.apache.org>
List-Id: <dev.cassandra.apache.org>
Reply-To: dev@cassandra.apache.org
Delivered-To: mailing list dev@cassandra.apache.org
Received: (qmail 56987 invoked by uid 99); 15 Aug 2013 17:01:50 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 17:01:50 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [50.116.4.34] (HELO madrose.net) (50.116.4.34)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 17:01:46 +0000
Received: (qmail 6825 invoked by uid 89); 15 Aug 2013 13:01:25 -0400
Received: from cpe-76-168-82-152.socal.res.rr.com (HELO u30x5.madrose.net)
 (mosfeq@madrose.net@76.168.82.152)
  by madrose.net with AES128-SHA encrypted SMTP; 15 Aug 2013 13:01:25 -0400
Date: Thu, 15 Aug 2013 10:01:24 -0700
Message-ID: <867gfmga6z.wl%mosfeq-cassandra@madrose.net>
From: Mosfeq Rashid <mosfeq-cassandra@madrose.net>
To: dev@cassandra.apache.org
Subject: Re: CQL 3 Binary protocol spec mismatch
In-Reply-To: 
 <CAAam9ss=37S2AGceABZ9kwBVXZ0+LqJwSBQzkT6ZPDBohJz0cA@mail.gmail.com>
References: <86a9kjg9fh.wl%mosfeq-cassandra@madrose.net>
	<CAAam9svTruX8ZH20w95Uq+sbNrOMQsZK5Lqi+S_bG-EYjYAFEA@mail.gmail.com>
	<868v03g7z3.wl%mosfeq-cassandra@madrose.net>
	<CAAam9ss=37S2AGceABZ9kwBVXZ0+LqJwSBQzkT6ZPDBohJz0cA@mail.gmail.com>
User-Agent: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/23.4 Mule/6.0
 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Virus-Checked: Checked by ClamAV on apache.org


The problem was that utf8 representation of the string was confusing emacs
buffer for some reason by nicely removing the metadata part at the correct
place.  Emacs is really nice, isn't it!  It became obvious once I tried to
look at the binary. Thanks for providing the clue.

Yes, I am writing a ODM client for node.js. 

By the way, where is is type information for the clustering column stored.
The type information all the other columns are available in
system.schema_columnfamilies and system.columns.  I sure it is somewhere,
because DESCIBE shows it. Thanks.

--
Mosfeq

At Thu, 15 Aug 2013 10:43:38 -0500,
Tyler Hobbs <tyler@datastax.com> wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Can you also describe the query you're running and paste the actual entire
> binary response (from the header to the end)?
> 
> By the way, are you writing a new client?
> 
> 
> On Wed, Aug 14, 2013 at 6:37 PM, Mosfeq Rashid <mosfeq-cassandra@madrose.net
> > wrote:
> 
> >
> > Thanks for the quick response.
> >
> > This is what I am getting:
> >
> > <row-count><value-col1-len><value-col1><value-col2-len><value-col2><value-col1-len><value-col1>...
> >
> > As you see, there is no metadata before the row-count.
> >
> > All the others messages I have tried like create, error, etc. are sending
> > response as expected in the spec.
> >
> > By I am running Ubuntu 13.04 and the binary distribution.
> >
> > --
> > Mosfeq
> >
> > At Wed, 14 Aug 2013 18:09:39 -0500,
> > Tyler Hobbs <tyler@datastax.com> wrote:
> > >
> > > Can you provide more details on exactly what's being returned?  As far
> > as I
> > > know, ResultMessages of type "ROWS" should always start with metadata,
> > and
> > > I haven't seen a case where it's missing in 1.2.
> > >
> > >
> > > On Wed, Aug 14, 2013 at 6:05 PM, Mosfeq Rashid <
> > mosfeq-cassandra@madrose.net
> > > > wrote:
> > >
> > > >
> > > > The response to the Select query is supposed to have metadata before
> > row
> > > > data is provided.  But in case of C* 1.2.5 and 1.2.8, I only get the
> > row
> > > > data.  As far as I understand binary protocol, the message should have
> > all
> > > > the data to parse it.  Does anyone know what I am missing?
> > > >
> > > > --
> > > > Mosfeq
> > > >
> > > >
> > >
> > >
> > > --
> > > Tyler Hobbs
> > > DataStax <http://datastax.com/>
> >
> 
> 
> 
> -- 
> Tyler Hobbs
> DataStax <http://datastax.com/>