Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAGjKECFeE2_i1dpm3=RBiGqnFFgxAuO+QVKuzYHdyxXA4Nbbbw@mail.gmail.com>
References: <1311376206.5719.147.camel@erebus.lan>
	<CAJG-trp9DDCE8eWTUt_fW5soaY-PKHHHDOtWniwoA8OYLKL-5Q@mail.gmail.com>
	<1311435559.5719.159.camel@erebus.lan>
	<CAGjKECFeE2_i1dpm3=RBiGqnFFgxAuO+QVKuzYHdyxXA4Nbbbw@mail.gmail.com>
Date: Sun, 24 Jul 2011 11:37:27 +0300
Message-ID: 
 <CAGjKECFJMFYS8KQHe6XCwkL4bhiaFzKU5Lxs9jPsE=OyuSZOjw@mail.gmail.com>
Subject: Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
From: David Boxenhorn <david@citypath.com>
To: dev@cassandra.apache.org
Content-Type: multipart/alternative; boundary=0015174c388ec5bea004a8cc9ba4

--0015174c388ec5bea004a8cc9ba4
Content-Type: text/plain; charset=ISO-8859-1

I meant "lax mode" not "lax version".

On Sun, Jul 24, 2011 at 11:33 AM, David Boxenhorn <david@citypath.com>wrote:

> Could we have a strict mode that would enforce quoting terms (this would be
> used in code) and a lax version that could be used in interactive mode,
> where backward compatibility is not so important?
>
>
> On Sat, Jul 23, 2011 at 6:39 PM, Eric Evans <eevans@rackspace.com> wrote:
>
>> On Fri, 2011-07-22 at 21:29 -0500, paul cannon wrote:
>> > I definitely vote for reserving words that are expected to be needed
>> > in the future. It seems we have a pretty good chance of predicting
>> > most of the syntactical needs for the next couple years (especially
>> > with suggestions from common SQL variants), and the (hopefully) rare
>> > exceptions could get their major version bumps.
>>
>> I agree that of the 3, the "reserve future keywords; bump major when
>> expanding the list becomes necessary" option looks the best on paper,
>> but I'm skeptical that it will work in practice.
>>
>> Reserving SQL keywords is a given (we should probably do that anyway),
>> but that wouldn't have been enough to catch the case that tripped us up,
>> ("type" is not a reserved word).  And, considering how much
>> back-and-forth there is over syntax, before, during, and after an
>> implementation, I could definitely see us bumping that major more than
>> once every 2 years.
>>
>> It *could* work, it would just require a great deal of discipline.
>>
>> > 2 and 3 feel like they would cripple CQL too much.
>>
>> Option 2 isn't so much crippling IMO, as it is weak.  That being said, I
>> already council people to quote all of their terms for everything but
>> interactively entered queries or trivial tests, so it doesn't seem like
>> *too* much of a stretch.
>>
>> For the record, I dislike all 3 of these options and am hoping someone
>> offers an alternative that blows me away. :)
>>
>>
>> > On Fri, Jul 22, 2011 at 6:10 PM, Eric Evans <eevans@rackspace.com>
>> > wrote:
>> >
>> > >
>> > > I just ran into an issue where CQL queries that were written at the
>> > time
>> > > of 0.8.0 no longer work against 0.8.1.  This was caused by r1130200
>> > > (CASSANDRA-1709) which introduced ALTER support.  The queries in
>> > > question made use of unquoted terms for one of the newly added
>> > keywords
>> > > ("type" in this case though any one of "alter", "table" or "add"
>> > would
>> > > have caused the same problem).
>> > >
>> > > This case never occurred to me, but it is fairly serious since it
>> > breaks
>> > > the expectation that code will remain backward compatible.  The
>> > options
>> > > I see are:
>> > >
>> > > 1. Bump the major of the language version when new keywords are
>> > added.
>> > > 2. Set the expectation that unquoted terms could collide with future
>> > > keywords.
>> > > 3. Disallow the unquoted term variant (would require bumping the
>> > major
>> > > once).
>> > >
>> > > #1 sucks because building out new features that would otherwise be
>> > > backward compatible will result in a major bump.  Looking at the
>> > roadmap
>> > > and trying to reserve everything now that we'll need for the
>> > foreseeable
>> > > future might make this less of an issue though.
>> > >
>> > > I have a feeling that #2 is easier said than done.  So long as we're
>> > > allowing the unquoted form, people will use it and be surprised when
>> > > bit.  Aside from that it seems OK.
>> > >
>> > > #3 is probably the most technically correct solution, but would make
>> > > hand-crafted queries entered into interactive interpreters less
>> > > friendly.
>>
>> --
>> Eric Evans
>> eevans@rackspace.com
>>
>>
>

--0015174c388ec5bea004a8cc9ba4--