I think we agree then!
The fact that people misuse Cassandra is a whole separate issue and
shouldn't hold the rest of us back. Adding obfuscation to CQL3 isn't the
solution.
Give me a few more days to put a complete list together of what I think
could be refined in CQL3 then we can pick this up a
yes. It doesn't use foreign keys or any constraints, they slow things down.
Exactly what you do not want. Check the history of the "features" that do
read before write. Counters, the old read before write secondary indexes,
the new collection functions that impose read before write.
Once people s
Totally agree, simple is good.
I want to refine the interface - the storage engine is fabulous as-is.
ap
On Wed, Mar 6, 2013 at 8:29 AM, Edward Capriolo wrote:
> Not to say that you can not do it. Or that it is impossible to do
> correctly, but currently Cassandra does not allow it's validat
*>
http://www.edwardcapriolo.com/roller/edwardcapriolo/entry/schema_vs_schema_less
*
Thanks for the link Ed, I'm aware of all that.
*> Does your the tool handle the fact that foreign keys do not work?
*
yes. It doesn't use foreign keys or any constraints, they slow things down.
*> how are your de
Not to say that you can not do it. Or that it is impossible to do
correctly, but currently Cassandra does not allow it's validation to accept
parameters per column. IE you can set a column to be varchar UTF8Type, or
int int32Type but you CAN'T attach more properties to that type, such as
the size o
http://www.edwardcapriolo.com/roller/edwardcapriolo/entry/schema_vs_schema_less
Does your the tool handle the fact that foreign keys do not work? Or for
that matter, how are your dealing with the fact that a "primary key" in
cassandra is nothing like a "primary key" in a RDBMS?
Generally under th
Hi Tristan,
I've spent the last couple weekends testing the CRUD DML stuff and its very
close to meeting that objective (although NULL handling needs some tuning).
The main hiccups are in the JDBC driver which I have been working through
with Rick - once he accepts my patches it'll be pretty soli
Sylvain,
All I'm trying to do is make Cassandra work with existing ETL, ORM &
desktop tools a bit better.
I think that is a worthy cause.
ap
On Tue, Mar 5, 2013 at 8:20 PM, Sylvain Lebresne wrote:
> > This is just one of a few small adjustments that can be made to the
> grammar
> > to make e
On Tue, Mar 5, 2013 at 10:20 AM, Sylvain Lebresne wrote:
> > This is just one of a few small adjustments that can be made to the
> grammar
> > to make everyone's life easier while still maintaining the spirit of
> NOSQL.
>
> To be clear, I am *not* necessarily against making CQL3 closer to the
> A
> This is just one of a few small adjustments that can be made to the
grammar
> to make everyone's life easier while still maintaining the spirit of
NOSQL.
To be clear, I am *not* necessarily against making CQL3 closer to the
ANSI-SQL
as a convenience. But only if that doesn't compromise the langu
Hi Sylvain,
I disagree. Actually, CQL3 is really close to being a faithful subset of
ANSI-SQL, which is rather exciting.
This is just one of a few small adjustments that can be made to the grammar
to make everyone's life easier while still maintaining the spirit of NOSQL.
The semantics of how th
> 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.
>
CQL3 is *not* ANSI-SQL compliant and will never be. It's not even SQL.
> I would like to propose that the column length be allowed
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 VARC
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 ema
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
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
speci
*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
17 matches
Mail list logo
