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)
Subject: Backward incompatible CQL changes 0.8.0 -> 0.8.1
From: Eric Evans <eevans@rackspace.com>
To: dev@cassandra.apache.org
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 22 Jul 2011 18:10:06 -0500
Message-ID: <1311376206.5719.147.camel@erebus.lan>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


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.

Thoughts?

-- 
Eric Evans
eevans@rackspace.com