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 <eev...@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 <eev...@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
> eev...@rackspace.com
>
>
