You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Ariel Scarpinelli (JIRA)" <ji...@apache.org> on 2016/10/19 14:07:58 UTC
[jira] [Comment Edited] (CASSANDRA-9928) Add Support for multiple
non-primary key columns in Materialized View primary keys
[ https://issues.apache.org/jira/browse/CASSANDRA-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15588847#comment-15588847 ]
Ariel Scarpinelli edited comment on CASSANDRA-9928 at 10/19/16 2:07 PM:
------------------------------------------------------------------------
Why not letting people decide?
If you implement [~thobbs] solution then people simply gets warned: "non-PK columns participating in MV PKs will need to be updated together". Then it becomes the user responsibility to choose if they prefer to be tied to that restriction, or use a single column (which is tied to that restriction anyway, but since you always update columns in a minimum set of 1 ... :-D) . The current way it is implemented you are not letting people with other choice than fabricating a "fake" column that concatenates values or so... which effectively translates in having to update in tandem anyways but also adding complexity and repeated data.
Also even better, you can start with the restriction as a step solution, and then relax the restriction with the other implementation. Your current decision was simply to leave it unattended for over a year I would guess in the discussion of how to implement it.
was (Author: ascarpinelli):
Why not letting people decide?
If you implement [~thobbs] solution then people simply gets warned: "non-PK columns participating in MV PKs will need to be updated together". Then it becomes the user responsibility to choose if they prefer to be tied to that restriction, or use a single column (which is tied to that restriction anyway, but since you always update columns in a minimum set of 1 ... :-D) . The current way it is implemented you are not letting people with other choice than fabricating a "fake" column that concatenates values or so... which effectively translates in having to update in tandem anyways but also adding complexity and repeated data.
> Add Support for multiple non-primary key columns in Materialized View primary keys
> ----------------------------------------------------------------------------------
>
> Key: CASSANDRA-9928
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9928
> Project: Cassandra
> Issue Type: Improvement
> Reporter: T Jake Luciani
> Labels: materializedviews
> Fix For: 3.x
>
>
> Currently we don't allow > 1 non primary key from the base table in a MV primary key. We should remove this restriction assuming we continue filtering out nulls. With allowing nulls in the MV columns there are a lot of multiplicative implications we need to think through.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)