bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
*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.
Is CQL3 too strict with bound variables?
Just posting this as more of a talking point around comparing the behavior of classical RDMBS to Cassandra. This bug is fixable over in the JDBC driver, but look at isolation #2 & exception B: http://code.google.com/a/apache-extras.org/p/cassandra-jdbc/issues/detail?id=72 It's coming from the server. Should Cassandra be more tolerant of feeding numbers into VARCHAR columns and vice-versa or is that the job of the client driver? ap
Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
It might be reasonable to enforce length on byte and string since this is
an upper limit, but just adding it to the grammer for compatability is just
more grammer. Personally I like nosql because of the nogrammer part, CQL
create table is not toocumbersome butI dont want to jump through hoops
specifying stuff that is not actually important in the final outcome.
On Sat, Mar 2, 2013 at 6:11 AM, Andrew Prendergast 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.
>
Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
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"
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.
Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
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
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"
> 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.
>
Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements
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 []
| CHAR []
| CHARACTER VARYING
| CHAR VARYING
| VARCHAR
...
4) If is omitted, then a 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 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
> 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" <
> a...@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.
> >
>
