incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Prendergast ...@andrewprendergast.com>
Subject Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
Date Sun, 03 Mar 2013 01:10:21 GMT
Hi Ed,

totally get the reasoning behind NOSQL and that it'll never be 100%
ANSI-SQL.. this is more about making the core functionality you do have
compatible with existing clients, otherwise why bother implementing a JDBC
+ SQL interface?

Cassandra is more than capable of accommodating say a VARCHAR(256) or a
VARCHAR(MAX) column, and thus shouldn't throw an exception.

The Ansi spec says:

         <character string type> ::=
                CHARACTER [ <left paren> <length> <right paren> ]
              | CHAR [ <left paren> <length> <right paren> ]
              | CHARACTER VARYING <left paren> <length> <right paren>
              | CHAR VARYING <left paren> <length> <right paren>
              | VARCHAR <left paren> <length> <right paren>

...


4) If <length> is omitted, then a <length> of 1 is implicit.


Right now, any existing JDBC/SQL client that tries to create a table with
string column > 1 character long will not be compatible with Cassandra.

For the sake of compatibility, I propose that the essential stuff (CREATE,
SELECT, INSERT, UPDATE, DELETE) should "accomodate" the most basic of
ANSI-SQL grammar and that the JDBC driver should behave similarly to
existing JDBC drivers.

I'm picking through where that isn't the case over the next few days. With
a few tiny adjustments we can make CQL3 very compatible with an existing
world of rich SQL-based client apps while still remaining faithful to the
NOSQL abstraction.

ap



On Sun, Mar 3, 2013 at 5:50 AM, Edward Capriolo <edlinuxguru@gmail.com>wrote:

> If the syntax effectively does nothing I do not see the point of adding it.
> CQL is never going to be 100% compatible ANSI-SQL dialect.
>
> On Sat, Mar 2, 2013 at 12:19 PM, Michael Kjellman
> <mkjellman@barracuda.com>wrote:
>
> > Might want to create a Jira ticket at issues.apache.org instead of
> > submitting the bug report thru email.
> >
> > On Mar 2, 2013, at 3:11 AM, "Andrew Prendergast" <
> ap@andrewprendergast.com>
> > wrote:
> >
> > > *DESCRIPTION*
> > >
> > > When creating a table in all ANSI-SQL compliant RDBMS' the VARCHAR
> > datatype
> > > takes a numeric parameter, however this parameter is generating errors
> in
> > > CQL3.
> > >
> > > *STEPS TO REPRODUCE*
> > >
> > > CREATE TABLE test (id BIGINT PRIMARY KEY, col1 VARCHAR(256)); // emits
> > Bad
> > > Request: line 1:54 mismatched input '(' expecting ')'
> > >
> > > CREATE TABLE test (id BIGINT PRIMARY KEY, col1 VARCHAR); // this works
> > >
> > > *SUGGESTED RESOLUTION*
> > >
> > > The current fail-fast approach does not create the column so that the
> > user
> > > is 100% clear that the length parameter means nothing to NOSQL.
> > >
> > > I would like to propose that the column length be allowed in the
> grammar
> > > (but ignored by cassandra), allowing better ANSI-SQL client
> > compatibility.
> >
> > Copy, by Barracuda, helps you store, protect, and share all your amazing
> >
> > things. Start today: www.copy.com.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message