[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17551248#comment-17551248
]
David Capwell commented on CASSANDRA-16844:
-------------------------------------------
bq. FTR if it comes to revert or break people, break people
4.1 is a minor release and this is a feature and not a critical bug fix...
breaking people in a minor goes against our previous promises
bq. 1) Could be reverting in 4.1 and keeping it in trunk for the next major, as
originally intended. Probably with a note in NEWS.txt.
Cool with me, but we would need to settle the "what is trunk" debate... right
now trunk is 4.x and we don't have a 5.x, so we need to fork (or saying next
release is 5.0 so adding breaking changes 2y after 4.0, which feels very very
quick to me)
bq. 2) Seems a bit cumbersome, and we would probably want to get rid of the
flag on trunk.
Same as previous point, in 5.0 we can drop the flag sure, we just don't have a
5.0 atm. We could also add a yaml property to control the default behavior, so
users who wish to have the 5.0 logic can avoid the flag and rely on the yaml,
but that has the same issue as we would drop in 5.0 (though we have ways to
deal with that atm)
bq. 3) Moving to the end makes compatibility better in most cases but it
doesn't guarantee it.
Agree, it doesn't mean no one will break, its just hoping we break less people.
One could argue its the same as adding a column to a table, as users doing
"select *" would now notice them as well.
> Add number of sstables in a compaction to compactionstats output
> ----------------------------------------------------------------
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
> Reporter: Brendan Cicchi
> Assignee: Brandon Williams
> Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
