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 <edlinuxg...@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
> <mkjell...@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" <
> 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.
> >
>
