> CASSANDRA-11031
Yes, sorry for delay with #11031 dtests. I've ran updated dtests yesterday
and they were clean to merge. I just wanted to make sure someone else takes
a quick glance. By now they're merged, so hopefully today it's going to be
better.
As regards environmental timeouts, it looks l
cassandra-3.9
===
testall: 8 failures
org.apache.cassandra.cql3.ViewFilteringTest
.testPartitionKeyAndClusteringKeyFilteringRestrictions
org.apache.cassandra.cql3.ViewFilteringTest
.testMVCreationSelectRestrictions
org.apache.cassandra.cql
In this particular case, I'd say adding a bug fix release for every version
that's affected would be the right thing. The issue is so easily
reproducible and will likely result in massive data loss for anyone on 3.X
WHERE X < 6 and uses the "date" type.
This is how easy it is to reproduce:
1. St
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 you
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 Cassan
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 tonight,
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 restri
