cassandra-3.9
===
testall: 8 failures
org.apache.cassandra.cql3.ViewFilteringTest
.testPartitionKeyAndClusteringKeyFilteringRestrictions
org.apache.cassandra.cql3.ViewFilteringTest
.testMVCreationSelectRestrictions
We did 3.1.1 and 3.2.1, so there’s SOME precedent for emergency fixes, but we
certainly didn’t/won’t go back and cut new releases from every branch for every
critical bug in future releases, so I think we need to draw the line somewhere.
If it’s fixed in 3.7 and 3.0.x (x >= 6), it seems like
Common sense is what prevents someone from upgrading to yet another
completely unknown version with new features which have probably broken
even more stuff that nobody is aware of. The folks I'm helping right
deployed 3.5 when they got started because cassandra.apache.org suggests
it's acceptable
What's preventing the use of the 3.6 or 3.7 releases where this bug is
already fixed? This is also fixed in the 3.0.6/7/8 releases.
Michael
On 09/14/2016 08:30 PM, Jonathan Haddad wrote:
> Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back ported to
> 3.5 as well, and it makes
Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back ported to
3.5 as well, and it makes Cassandra effectively unusable if someone is
using any of the 4 types affected in any of their schema.
I have cherry picked & merged the patch back to here and will put it in a
JIRA as well
Sorry, it seems that I did not provide enough details.
IN restrictions are supported on any clustering key as long as ALL the
previous clustering keys are restricted by an equality restrictions ( = or
IN ).
The only way to have a restriction on a clustering column if a previous one
has been
