Return-Path: X-Original-To: apmail-cassandra-dev-archive@www.apache.org Delivered-To: apmail-cassandra-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7EF16D0BE for ; Tue, 5 Mar 2013 20:46:42 +0000 (UTC) Received: (qmail 48481 invoked by uid 500); 5 Mar 2013 20:46:41 -0000 Delivered-To: apmail-cassandra-dev-archive@cassandra.apache.org Received: (qmail 48454 invoked by uid 500); 5 Mar 2013 20:46:41 -0000 Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list dev@cassandra.apache.org Received: (qmail 48444 invoked by uid 99); 5 Mar 2013 20:46:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Mar 2013 20:46:41 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.215.44] (HELO mail-la0-f44.google.com) (209.85.215.44) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Mar 2013 20:46:37 +0000 Received: by mail-la0-f44.google.com with SMTP id eb20so6703379lab.17 for ; Tue, 05 Mar 2013 12:46:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=9WZ+Yqt46JnCqysiXK0DYLu+l2LZK+vMtQr7snezEH8=; b=kurAbhJyVbklMthWYc2EweTNAlRtOWfaZwX/8PThhbasy4eHAPBOEnbE44G583kqIP ifx5pgnZbrXjMnVSAweBzw4PqytfPGTCY6fft/tW+2IEUF6YH+2u34Nki/0Awo8WPAbX W919tHnQYoQ6aU6BxJ3ZHYkLhNxH1DwFgcmzA9Hys9vV3qGDe5UU0e5+gEOqzV9t0wi9 ifA+hb1rqAJpJyVZqUwpHxKolJ0nkNWgvxEpdsg4I5/Se1LAtFZqpICT3hLpbhbr672f A5Rf+jbWdP4/US/8ly/My/Ahtcwl1UZUYoPhCTU4qOy8euKdbkKSSBAPjshA84caRZIU 7Vcg== MIME-Version: 1.0 X-Received: by 10.112.41.136 with SMTP id f8mr6365778lbl.121.1362516374113; Tue, 05 Mar 2013 12:46:14 -0800 (PST) Received: by 10.114.23.234 with HTTP; Tue, 5 Mar 2013 12:46:13 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 07:46:13 +1100 Message-ID: Subject: Re: bug report - CQL3 grammar should ignore VARCHAR column length in CREATE statements From: Andrew Prendergast To: dev@cassandra.apache.org Content-Type: multipart/alternative; boundary=e0cb4efe34447afb5704d73390ac X-Gm-Message-State: ALoCoQkmaVv1NskTheHHH5LhJ75VOBv2xsSwP5lrkWnCSjUPU1oHod0D3ZlotGqE9kWuc9CvyCDg X-Virus-Checked: Checked by ClamAV on apache.org --e0cb4efe34447afb5704d73390ac Content-Type: text/plain; charset=ISO-8859-1 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 solid in terms of cross-platform compatibility. On the DDL, I personally have a need for similar compatibility. One app I'm working on programmatically creates the schema for a rather big ETL environment. It includes a very nice abstraction that creates databases and tables to accommodate tuples as they pass through the pipeline and behaves the same regardless of which DBMS is being used as the storage engine. This is possible because it turns out there is a subset of DDL that is common to all of the DBMS platforms and it would be very useful to see that in Cassandra. ap On Tue, Mar 5, 2013 at 8:26 PM, Tristan Tarrant wrote: > 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 > > ANSI-SQL > > as a convenience. But only if that doesn't compromise the language > > "integrity" > > and is justified. Adding a syntax with a well known semantic but without > > > > To me database DDL (such as the CREATE statement we are talking about) is > always going to be handled in a custom fashion by applications. > While ANSI SQL compatibility for CRUD operations is a great objective, I > don't think it really matters for DDL. > > Tristan > --e0cb4efe34447afb5704d73390ac--