Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 19 Mar 2014 15:37:44 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12702400.1395243380440.104300.1395243464081@arcas>
In-Reply-To: <JIRA.12702400.1395243380440@arcas>
References: <JIRA.12702400.1395243380440@arcas>
Subject: [jira] [Created] (CASSANDRA-6888) Store whether a counter sstable
 still use some local/remote shards in the sstable metadata
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Sylvain Lebresne created CASSANDRA-6888:
-------------------------------------------

             Summary: Store whether a counter sstable still use some local/remote shards in the sstable metadata
                 Key: CASSANDRA-6888
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6888
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Sylvain Lebresne
             Fix For: 2.1


CASSANDRA-6504 has made so we don't distinguish different type of shard in counters. Yet, even though we don't generate those local/remote type of shards, those won't disappear just by running upgradesstable, they need to be compacted away (and even then, they really only disappear if there has been a new update on the counter post-6504).

But we want to get rid of those ultimately, since they make things like CASSANDRA-6506 less optimal. Now, even though the final step of that remain to be discussed, the first step is probably to keep track of whether such shard still exist in the system or not. That part is simple, we can just store a boolean in the SSTableMetadata to say whether or not said sstable still has at least one Cell using such old shard type. 


--
This message was sent by Atlassian JIRA
(v6.2#6252)