Re: Paying off tech debt and correctly naming things

Poor and out-of-date naming of things is probably the least serious part of our technical debt. Bad factoring, and straight-up poorly written components is where it’s really at. Doing a big rename for rename sake alone does more harm than it is good, sometimes. Some of us have big patches in

Re: Paying off tech debt and correctly naming things

Jon, Thanks for bringing up this topic. I'll admit that I've been around this code base for long enough, and have enough accumulated history, that I probably can't fully appreciate the impact for a newcomer wrt naming. However, as Josh points out, this situation probably happens to "every

Re: Paying off tech debt and correctly naming things

Cool. I think there’s general agreement that doing this in as small bites as possible is going to be the best approach. I have no interest in mega patches. > The combined approach takes a > change that's already non-trivially dealing with complex subsystem > changes and injects a bunch of

RE: Paying off tech debt and correctly naming things

I agree with Jason Brown: good topic to address, effect not trivial. Going whole hog too risky. Careful meticulous small areas at a time with warning to everyone so they can chime in if they are working on that area and would prefer it left alone for now. I wouldn't want it to delay others

RE: Paying off tech debt and correctly naming things

Perfect! -Original Message- From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad Sent: Thursday, March 22, 2018 8:10 AM To: dev@cassandra.apache.org Subject: Re: Paying off tech debt and correctly naming things Cool. I think there’s general agreement that doing

Optimizing queries for partition keys

Cassandra devs, We use workflows in some of our clusters (running 3.0.15) that involve "SELECT DISTINCT key FROM..."-style queries. For some tables, we observed extremely poor performance under light load (i.e., a small number of rows per second and frequent timeouts), which we eventually traced

Re: Paying off tech debt and correctly naming things

> Some of us have big patches in flight, things that actually > pay off some technical debt, and dealing with such renames is rebase hell :\ For sure, but with a code-base this old / organically grown, I expect this will always be the case. If we're talking something as simple as an intellij

Re: Optimizing queries for partition keys

Syvlain explained the problem in CASSANDRA-4536: " Let me note that in CQL3 a row that have no live column don't exist, so we can't really implement this with a range slice having an empty columns list. Instead we should do a range slice with a full-row slice predicate with a count of 1, to make

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

Is OpenJDK really not addressing this at all? Is that because OpenJDK is beholden to Oracle somehow? This is a major disservice to Apache and the java ecosystem as a whole. When java was fully open sourced, it was supposed to free the ecosystem to a large degree from Oracle. Why is OpenJDK being

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

On 03/22/2018 05:30 PM, Michael Shuler wrote: > Ubuntu 16.04 (Bionic (near release)) Ubuntu 18.04 (Bionic) :) Michael - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail:

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

See the legal-discuss@ thread: https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201803.mbox/browser . TL;DR jlink-based distributions are not gonna fly due to OpenJDK's license, so let's focus on other paths forward. On Thu, Mar 22, 2018 at 2:04 PM, Carl Mueller

Re: Optimizing queries for partition keys

You should check the 3.x release. CASSANDRA-10657 could have fixed your problem. On Thu, Mar 22, 2018 at 9:15 PM, Benjamin Lerer wrote: > Syvlain explained the problem in CASSANDRA-4536: > " Let me note that in CQL3 a row that have no live column don't exist, so >

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

As I mentioned in IRC and was pasted earlier in the thread, I believe the easiest path is to follow the major releases of OpenJDK in the long-term-support Linux OS releases. Currently, Debian Stable (Stretch), Ubuntu 16.04 (Bionic (near release)), and Red Hat / CentOS 7 all have OpenJDK 8 as the