Re: CASSANDRA-8527

I think that's a good idea for 4.x, but not so for current branches. I think as long as we document it well for 4.0 upgrades it's not so much of a problem. Obviously there will be cases of queries failing that were previously succeeding but we can already use tombstone_failure|warn_threshold to tun

Re: CASSANDRA-8527

Maybe I should rephrase my words but I think you got that thread. Singleton is one big thing and possibly we can use powermock, or totally get rid of it. But without mock, I'm frustrated to work on so-called unit test cases. On Thu, Dec 21, 2017 at 2:28 PM, Jeff Jirsa wrote: > On Thu, Dec 21, 20

Re: CASSANDRA-8527

On Thu, Dec 21, 2017 at 12:33 PM, Qingcun Zhou wrote: > I brought up Mockito topic couple of months ago but some committers don't > think we should introduce more dependencies. > > I don't see any indication of this in the dev@ archives. There was a comment from a contributor who said they weren'

Re: CASSANDRA-8527

On Tue, Dec 19, 2017 at 11:07 PM, Alexander Dejanovski < a...@thelastpickle.com> wrote: > Hi folks, > > I'm working on CASSANDRA-8527 > and would need to > discuss a few things. > > The ticket makes it visible in tracing and metrics that rows

Re: CASSANDRA-8527

The question isn’t so much about reporting them (we should), it’s about the behavior of tombstone_warn_threshold and tombstone_failure_threshold. The patch changes the behavior to include the number of rows that are passed over due to the range tombstones. We’re interested in feedback on if it

Re: CASSANDRA-8527

+1 to report range tombstones. This one is quite tricky indeed to track +1 to Mockito too, with the reserve that it should be used wisely On Thu, Dec 21, 2017 at 9:11 PM, Jon Haddad wrote: > I had suggested to Alex we kick this discussion over to the ML because the > change will have a signific

Re: CASSANDRA-8527

I brought up Mockito topic couple of months ago but some committers don't think we should introduce more dependencies. On Thu, Dec 21, 2017 at 12:11 PM, Jon Haddad wrote: > I had suggested to Alex we kick this discussion over to the ML because the > change will have a significant impact on the b

Re: CASSANDRA-8527

I had suggested to Alex we kick this discussion over to the ML because the change will have a significant impact on the behavior of Cassandra when doing reads with range tombstones that cover a lot of rows. The behavior now is a little weird, a single tombstone could shadow hundreds of thousand

RE: How to fetch replication factor of a given keyspace

Yeah, I tried doing it. The problem is when I call: Schema.instance.getKeyspaceInstance(keyspaceName) or getKeyspaceMetadata(); It returns null for all keyspace names. Is it expected? Thanks, Preetika -Original Message- From: Nate McCall [mailto:zznat...@gmail.com] Sent: Wednesday, Dec

Re: Test patch to Cassandra.3.0.15 using dtests

hi sergey: took much longer than i hoped but i have a patch up for review to hopefully improve the dtest user experience. https://issues.apache.org/jira/browse/CASSANDRA-14134 i sent an email summarizing it earlier this morning in a separate thread. i moved all the undocumented environment var

Re: Cassandra Dtests: skip upgrade tests

As part of the work i did for https://issues.apache.org/jira/browse/CASSANDRA-14134, one of the things I did was add a new command line argument “--execute-upgrade-tests”. all the upgrade tests are now annotated with an upgrade_test pytest annotation. by default they aren’t run. adding a single

[Patch Available for Review!] CASSANDRA-14134: Migrate dtests to use pytest and python3

I just created https://issues.apache.org/jira/browse/CASSANDRA-14134 which includes tons of details (and a patch available for review) with my efforts to migrate dtests from nosetest to pytest (which ultimately ended up also including porting the ode from python 2.7 to python 3). I'd love if pe