[jira] [Commented] (CASSANDRA-14557) Consider adding default and required keyspace replication options

[Sumanth Pasupuleti (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406552#comment-17406552
 ] 

Sumanth Pasupuleti commented on CASSANDRA-14557:


[~azotcsit] Thank you, responded to your comments and incorporated the 
feedback. https://github.com/sumanth-pasupuleti/cassandra/tree/14557-trunk

> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
>  Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right 
> now - the system_auth table for example is created with RF=1 (to take into 
> account single node setups afaict from CASSANDRA-5112), and a user can 
> further create a keyspace with RF=1 posing availability and streaming risks 
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
>  # {{default_keyspace_rf}} (default: 1) - If replication factors are not 
> specified, use this number.
>  # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from 
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
>  * Provide defaults for new keyspaces created with SimpleStrategy or 
> NetworkTopologyStrategy (CASSANDRA-14303)
>  * Make the automatic token [allocation 
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
>  interface more intuitive allowing easy use of the new token allocation 
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply 
> don’t set the setting. For backwards compatibility the default remains 1 and 
> C* would create with RF=1, and would default to current behavior of allowing 
> any RF on keyspaces.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Commented] (CASSANDRA-16806) Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it

[Aleksei Zotov (Jira)]

[ 
https://issues.apache.org/jira/browse/CASSANDRA-16806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406470#comment-17406470
 ] 

Aleksei Zotov commented on CASSANDRA-16806:
---

[~blerer]

That makes sense to me. I'm almost done with the change, the only remaining 
part is to update the tests to work with multiple partition keys and clustering 
columns to ensure the current conversion logic is convenient for composite 
types.

In the meantime, I have a question on the VTs design. Currently TTL is not 
supported on VTs (restricted on the query level) which makes perfect sense to 
me. Similarly, I expected to see that custom timestamp ({{USING TIMESTAMP}} 
statement) is restricted on the query level. However, it seems to be supported. 
If it is just an oversight, I'd like to fix it as a part of the current ticket. 
If it is a part of the original design, I'd like to understand the use cases to 
incorporate it to  the current change. Please, let me know your thoughts.

> Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation 
> allows it
> ---
>
> Key: CASSANDRA-16806
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16806
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> {{TRUNCATE}} statements are currently not supported by Virtual Tables. For 
> some Virtual Tables it makes sense to allow it.
> It can be done by adding a {{truncate}} method to the {{VirtualTable}} 
> interface and calling that method from {{TruncateStatement}}. The default 
> implementation of the method should be to fire an {{InvalidRequestException}} 
> saying that truncate is not supported on that specific table.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org