cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (Jira)" <>
Subject [jira] [Commented] (CASSANDRA-16835) Scrub still uses "row" to mean "partitions", and has broken code
Date Mon, 16 Aug 2021 18:59:00 GMT


Brandon Williams commented on CASSANDRA-16835:

That looks like what we need, +1.

> Scrub still uses "row" to mean "partitions", and has broken code
> ----------------------------------------------------------------
>                 Key: CASSANDRA-16835
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tool/nodetool
>            Reporter: Ekaterina Dimitrova
>            Assignee: Ekaterina Dimitrova
>            Priority: Normal
>             Fix For: 3.11.x, 4.0.x, 4.x
> 2 issues in the scrub code:
>  1) It still uses "row" to mean "partition". And not only in the code, but also in user
messages. As we've fairly systematically remove such instances elsewhere in 3.0+, having it
in scrub is going to confuse users which will almost surely misinterpret the results. If scrub
says that it dropped 2 unreadable "rows" from your sstable, you might be ok with that when
we're actually talking about CQL rows, but not if we talk of 2 full partitions.
>  2) There is a branch at the end of scrub that is supposed to handle the case where scrubbing
a sstable generates no output at all (the sstable is completely hosed usually), mostly providing
a more user friendly message. The code is broken (and has been for a long time, since CASSANDRA-7066
I believe) however such that this branch can simply never be taken (even when it should).
While admittedly pretty minor, no reason to leave it that way.

This message was sent by Atlassian Jira

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message