[
https://issues.apache.org/jira/browse/CASSANDRA-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923122#action_12923122
]
Jonathan Ellis commented on CASSANDRA-1263:
-------------------------------------------
bq. Because user-def strats can require arbitrary opts, I can't easily verify
that they exist
you shouldn't be trying to. instead you should merely instantiate the
strategy, which should be responsible for throwing ConfigurationException if it
borks.
bq. Furthermore, I have to call getRF() is every place in the code that we ask
for the instance RF, and I can't guarantee that getRF() is non-trivial (and it
runs in tight loops).
Add a docstring saying that implementors of getRF (which becomes abstract) are
responsible for making it fast, which may or may not include caching it.
> Push replication factor down to the replication strategy
> --------------------------------------------------------
>
> Key: CASSANDRA-1263
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1263
> Project: Cassandra
> Issue Type: Task
> Components: Core
> Reporter: Jeremy Hanna
> Assignee: Jon Hermes
> Priority: Minor
> Fix For: 0.7.0
>
>
> Currently the replication factor is in the keyspace metadata. As we've added
> the datacenter shard strategy, the replication factor becomes more computed
> by the replication strategy. It seems reasonable to therefore push the
> replication factor for the keyspace down to the replication strategy so that
> it can be handled in one place.
> This adds on the work being done in CASSANDRA-1066 since that ticket will
> make the replication strategy a member variable of keyspace metadata instead
> of just a quasi singleton giving the replication strategy state for each
> keyspace. That makes it able to have the replication factor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
