Mailing-List: contact client-dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: client-dev@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of juho.makinen@gmail.com
 designates 209.85.214.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=UdyE3TrtjXon4A1HjwbLNKsbjYintGvMA7/2K13Zc8oTaJWr4idhxRZURIA13KZMEl
         1349XoNuVEA0oTOq8FLNIaIzFYSk2AHTd0qNl37T3kWLTTjRi12gDA/XLzSvpkKJUax0
         gwSsa29W3hCjHswyyjKiU421t8dPBGT2sd5xY=
MIME-Version: 1.0
In-Reply-To: <1288900792.14765.32.camel@erebus.lan>
References: <1288887036.9620.33.camel@erebus.lan>
	<AANLkTi=1g6KdxJeSzmeb41Z1ee3dOhjJ7uN0_Rpco8gq@mail.gmail.com>
	<1288891732.9620.52.camel@erebus.lan>
	<AANLkTin7UDnZ3rbzdUsGbBJpzkYzq=y2E9T4P1qvmgDw@mail.gmail.com>
	<1288900792.14765.32.camel@erebus.lan>
Date: Fri, 5 Nov 2010 09:01:34 +0200
Message-ID: <AANLkTiktKouG8ZQT1oXu9e8Cs3sn=HTC+CY8JdFqbers@mail.gmail.com>
Subject: Re: Calling all library maintainers
From: =?ISO-8859-1?Q?Juho_M=E4kinen?= <juho.makinen@gmail.com>
To: client-dev@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm also all in for a query language. There has been some excellent
reasons already posted, but I have another good reason why a QL would
be better: maintaining the cluster.

Due to 0.7 the Thrift API has now multiple structures and functions to:
 - define indexes
 - create/drop/rename new column families
 - altering keyspaces (like replication factor)
 - describe keyspace
 - truncate a keyspace

and so on, I didn't even include all of those.

I believe that it's stupid to expose all these as function calls and
force client developers to implement some varying ways to call these
functions from command line to maintain the database. In my opinion a
uniform query language could make all these operations much easier and
much more user friendly. Also the CLI could be much easier as it could
just transfer the commands to the server.

 - Juho M=E4kinen

On Thu, Nov 4, 2010 at 9:59 PM, Eric Evans <eevans@rackspace.com> wrote:
> On Thu, 2010-11-04 at 21:28 +0200, Ran Tavory wrote:
>> A QL can shield clients from a class of changes, but OTOH will make
>> clients have to compose the query strings, where with type safe
>> libraries this job is somewhat easier. IMO in the near term
>> introducing a query language will make client dev somewhat harder b/c
>> of the (somewhat negligible) work of composing query strings and
>> mostly b/c I don't expect the QL to be stable at v1 so still a moving
>> target, but easier in the the long term mainly due to the hope that
>> the QL will stabilize.
>
> I think you could argue that it makes all of this easier. =A0Right now
> from Java you serialize a type to a byte[] whereas with the query
> language you'd serialize to a string term. =A0That's a bit more effort ou=
t
> of the gate for primitives like long for example, but consider the
> venerable TimeUUID that causes so much frustration. =A0I think it would b=
e
> much easier to take a timestamp and construct a term like
> TIMEUUID(<timestamp>) (or whatever), especially since that would work
> identically across all clients.
>
> And it's also worth pointing out that not all languages in use are
> statically typed, so even in the case of an int, or a long, it'd be
> easier (or as easy at least), to serialize that to a string like
> 100000L, than it would be to pack a binary string in network-order.
>
> As for not being stable, well, yeah it's going to need to bake a bit
> before being suitable for widespread use, but I raise it here not to
> encourage everyone to transition now, but so that you can help shape the
> outcome (if you're interested, of course).
>
>> One other benefit of query languages is that they make tooling a
>> little easier, one does not have to come up with a specific CLI
>> interpreter or a web interface with a set of input fields, you just
>> have to type your QL into a text box or a terminal like you do with
>> sql.
>> Long term I think I'm in for a QL (although I have to think about the
>> syntax you suggested) but I don't expect it to benefit client devs in
>> the near term even if it was ready today as an alternative to thrift.
>>
>> One small question, does this language tunnel through avro or thrift
>> calls? (Is >>> conn.execute() an avro or thrift call)
>
> It's avro for the simple reason that that's still sort of an
> experimental code path and seemed a less controverial sandbox. =A0When th=
e
> spec and implementation are complete, and if it gains suitable traction,
> I'd actually like to explore a customized transport and serialization.
>
> --
> Eric Evans
> eevans@rackspace.com
>
>