incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
Date Sat, 23 Jul 2011 15:39:19 GMT
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


Mime
View raw message