[jira] Commented: (CASSANDRA-1066) DatacenterShardStrategy needs enforceable and keyspace based RF

["Hudson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894378#action_12894378 ] 

Hudson commented on CASSANDRA-1066:
-----------------------------------

Integrated in Cassandra #506 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/506/])
    update {CHANGES,NEWS}.txt

Patch by eevans for CASSANDRA-1066
datacenter.properties no longer neeeded

Patch by eevans for CASSANDRA-1066
regenerated thrift code

Patch by eevans for CASSANDRA-1066
configurable options for replication strategies

Patch by Jeremy Hanna; review by eevans for CASSANDRA-1066


> DatacenterShardStrategy needs enforceable and keyspace based RF
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-1066
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1066
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jeremy Hanna
>            Assignee: Jeremy Hanna
>            Priority: Minor
>             Fix For: 0.7 beta 1
>
>         Attachments: 1066-3.txt, 1066-4.txt, 1066-5.txt, 1066-changes-patch.txt, 1066-external.patch, 1066-update.txt, 1066.txt, 1066.txt
>
>
> (Updated to reflect the true scope of this improvement along with decisions about implementation)
> Currently, the DatacenterShardStrategy reads in a properties file - datacenters.properties - to get a per-datacenter replication factor.
> This improvement would do away with a separate properties file for configuring per-datacenter replication in favor of configuring them on a per-keyspace basis.  This would allow clients to create a new keyspace with the configuration of the DatacenterShardStrategy as part of the keyspace definition.  It would also update the cassandra.yaml configuration parsing to allow users to configure their DSS from there as well. 
> The basic structure would not change and the KSMetaData would just contain additional configuration information - a map of configuration options.  That way, if other ReplicationStrategies in the future would like specific configuration options, they can use them as well.
> Further changes previously mentioned in this ticket involved enforcing the replication factor.  A separate ticket has been created to push the replication factor down to the replication strategy.  That facilitates enforcing the RF at that level.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.