[
https://issues.apache.org/jira/browse/CASSANDRA-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700761#comment-16700761
]
Benedict commented on CASSANDRA-14912:
--------------------------------------
I _think_ the easiest fix for preventing the exception is to simply return a RT
bound where the {{ColumnDefinition}} is definitely complex?
This might mean we return a RT that covers a non-existent column, but with your
change we *should* filter that out. But if we don't, that's fine, it's only a
best effort, and it won't actually cause us any problems.
FWIW, I've tried this change to confirm it works
[here|https://github.com/belliottsmith/cassandra/tree/14912-3.0-suggest].
> LegacyLayout errors on collection tombstones from dropped columns
> -----------------------------------------------------------------
>
> Key: CASSANDRA-14912
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14912
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Major
> Fix For: 3.0.x, 3.11.x
>
>
> When reading legacy sstables in 3.0, the dropped column records in table
> metadata are not checked when a collection tombstone is encountered. This
> means that if a collection column was dropped and a new column with the same
> name but a non-collection type subsequently added prior to upgrading to 3.0,
> reading any sstables containing the collection data will error. This includes
> reads done by upgradesstables, which makes recovery from this situation
> without losing data impossible. Scrub will clean the affected tables, but any
> valid data will also be discarded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
