cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Scarpinelli (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9928) Add Support for multiple non-primary key columns in Materialized View primary keys
Date Wed, 19 Oct 2016 14:07:58 GMT

    [ 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)

Mime
View raw message