Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BBFAFCD4A for ; Wed, 26 Jun 2013 13:22:22 +0000 (UTC) Received: (qmail 21968 invoked by uid 500); 26 Jun 2013 13:22:22 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 21685 invoked by uid 500); 26 Jun 2013 13:22:21 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 21638 invoked by uid 99); 26 Jun 2013 13:22:20 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Jun 2013 13:22:20 +0000 Date: Wed, 26 Jun 2013 13:22:20 +0000 (UTC) From: "Sylvain Lebresne (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CASSANDRA-5702) ALTER RENAME is broken in trunk MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylvain Lebresne updated CASSANDRA-5702: ---------------------------------------- Attachment: 5702.txt Attaching patch for this. Note that persisting those default columns implied to only rebuild CQL3 metadata once the CFMetaData is basically complete, hence the patch moves the calls to said rebuild a bit (it's a good thing anyway, we were calling that rebuild way too often). Also: * the patch fixes a small bug in CFMetaData.isThriftCompatible(). It was excluding way too much stuff post CASSANDRA-5125. * this happen to lift the limitation introduced by CASSANDRA-5531 (not a big deal but not a bad thing either). * I've also rewritten CFMetaData.isDense(). I don't think that was strictly necessary, but while trying to check it wasn't broken by the patch it felt it could be simplified/clarified. > ALTER RENAME is broken in trunk > ------------------------------- > > Key: CASSANDRA-5702 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5702 > Project: Cassandra > Issue Type: Bug > Reporter: Sylvain Lebresne > Assignee: Sylvain Lebresne > Fix For: 2.0 beta 1 > > Attachments: 5702.txt > > > CASSANDRA-5125 has broken {{ALTER RENAME}} when the column is a default alias (for thrift column families where the PK columns haven't been renamed yet). > The problem is basically that while we assign default aliases to PK columns when they don't have one, we currently "fake" those default aliases and do not persist them. Concretely, CFDefinition is aware of them, but CFMetaData is not, which break renaming post CASSANDRA-5125. > We could fix rename punctually, but there is another related problem: for the same reason, if you try to create an index on a column that is a non-renamed default alias, this doesn't work with the arguably confusing message "No column definition found for column X". Here again, we could fix it punctually, but it starts to sound like we need a more general fix. > So I suggest stopping to "fake" those default aliases, but instead to just create "real" aliases (that are known of CFMetaData and persisted in the schema) when there is none. After all, from a user point of view, why should a default column name be any special. And on top of fixing the issues above, this also: > # fix CASSANDRA-5489 in a somewhat simpler way > # makes it easier for clients reading the schema CFs. They won't to infer the default aliases anymore. > The only theoretical downside is that we lose the information that a given CQL3 column name is one assigned by default versus one set up by the user, but given the user can rename those column names anyway, not sure this matters in any way. -- 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: http://www.atlassian.com/software/jira