From commits-return-216285-archive-asf-public=cust-asf.ponee.io@cassandra.apache.org Sun Nov 18 19:04:09 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 7133718067C for ; Sun, 18 Nov 2018 19:04:08 +0100 (CET) Received: (qmail 77718 invoked by uid 500); 18 Nov 2018 18:04:07 -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 77638 invoked by uid 99); 18 Nov 2018 18:04:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Nov 2018 18:04:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id E4691CBC96 for ; Sun, 18 Nov 2018 18:04:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.501 X-Spam-Level: X-Spam-Status: No, score=-109.501 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id WvPOpEs5uqgV for ; Sun, 18 Nov 2018 18:04:06 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 969A75F432 for ; Sun, 18 Nov 2018 18:04:04 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 4A402E2633 for ; Sun, 18 Nov 2018 18:04:03 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id BB31423FBF for ; Sun, 18 Nov 2018 18:04:02 +0000 (UTC) Date: Sun, 18 Nov 2018 18:04:02 +0000 (UTC) From: "C. Scott Andreas (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CASSANDRA-10226) Support multiple non-PK cols in MV clustering key when partition key is shared 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-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas updated CASSANDRA-10226: ----------------------------------------- Component/s: Materialized Views > Support multiple non-PK cols in MV clustering key when partition key is shared > ------------------------------------------------------------------------------ > > Key: CASSANDRA-10226 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10226 > Project: Cassandra > Issue Type: Improvement > Components: Materialized Views > Reporter: Tyler Hobbs > Priority: Major > Labels: materializedviews > Fix For: 4.x > > > This issue is similar to CASSANDRA-9928, but with one key limitation: the MV partition key must match the base table's partition key. This limitation results in the base replica always pairing with itself as the MV replica. Because of this pairing, if the base replica is lost, any MV rows that would otherwise be ambiguous are also lost. This allows us to avoid the problem described in 9928 of not knowing which MV row to delete. > Although this limitation has the potential to be a bit confusing for users, I believe this improvement is still worthwhile because: > * The base table's partition key will often be a good choice for the MV partition key as well. I expect it to be common for users to partition data the same way, but use a different clustering order to optimize for (or allow for) different queries. > * It may take a long time to solve the problems presented in 9928 in general (if we can solve them at all). On the other hand, this is straightforward and is a significant improvement to the usability of MVs. > I have a minimal prototype of this that works well, so I should be able to upload a patch with thorough tests within the next few days. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org For additional commands, e-mail: commits-help@cassandra.apache.org