Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
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 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
> > 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
>
>
Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
I meant "lax mode" not "lax version".
On Sun, Jul 24, 2011 at 11:33 AM, David Boxenhorn 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 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
>> > 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
>>
>>
>
Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
On Sun, 2011-07-24 at 11:33 +0300, David Boxenhorn 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? It's possible, but the skeptic (cynic?) in me thinks that's just one more variable in the equation, and one people will frequently trip over. > > > On Fri, Jul 22, 2011 at 6:10 PM, Eric Evans > > > > 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. -- Eric Evans eev...@rackspace.com
Re: Backward incompatible CQL changes 0.8.0 -> 0.8.1
It should be strict by default. People who write code are trained to be careful (or should be). Interactive environments can set it to lax, if they want, for their user base. On Sun, Jul 24, 2011 at 8:25 PM, Eric Evans wrote: > On Sun, 2011-07-24 at 11:33 +0300, David Boxenhorn 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? > > It's possible, but the skeptic (cynic?) in me thinks that's just one > more variable in the equation, and one people will frequently trip over. > > > > > On Fri, Jul 22, 2011 at 6:10 PM, Eric Evans > > > > > 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. > > -- > Eric Evans > eev...@rackspace.com > >
