cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3919) Dropping a column should do more than just remove the definition
Date Tue, 09 Apr 2013 21:50:17 GMT


Aleksey Yeschenko commented on CASSANDRA-3919:

bq. Why do we only call discardDropped if it has re-added columns?

SelectStatement will reject unknown columns, so there is no need to do extra-filtering unless
some have been readded.

bq. Why is the dropped time the last part of the cell name? Isn't it the value as well? That
seems odd.

It's only in the value:

bq. Would prefer to store the values natively as micros rather than fix it up on load into

wfm, I just liked having it nicely-formatted in cqlsh.

bq. !cf.metadata().getDroppedColumns().isEmpty() could move into isDropped

Huh. Yes, it should. Or I could move it outside the while-loop.

bq. Leaning towards "we should probably not put this into 1.2 this late in the release cycle,"
is it going to kill people to wait for 2.0?


> Dropping a column should do more than just remove the definition
> ----------------------------------------------------------------
>                 Key: CASSANDRA-3919
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Aleksey Yeschenko
>              Labels: compaction, cql
>             Fix For: 1.2.5
> Dropping a column should:
> - immediately make it unavailable for {{SELECT}}, including {{SELECT *}}
> - eventually (i.e., post-compaction) reclaim the space formerly used by that column

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message