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

Eric Evans commented on CASSANDRA-1066:
---------------------------------------


A few issues, some of which we discussed on IRC, but I'll put them on record 
here anyway:
* I had mentioned on IRC that I thought "stragegy_options" was too generic, but 
it occurred to me that it's consistent with strategy_class. I still think it's 
too generic, but it's probably not worth changing without changing both (and 
it's probably not worth doing that).
* cassandra-cli will need updating so that it's possible create keyspaces with 
these options set (I'd just create another ticket and link it to this one).
* As mentioned on IRC, DD.readTablesFromYaml() hard-codes the strategy options 
to null
* In KSMetaData.deflate(); ks.strategy_options will never get assigned because 
it will always be null (that expression should test strategyOptions instead).

Also, are the system tests passing for you? I'm getting the following:

{noformat}
======================================================================
ERROR: system.test_thrift_server.TestMutations.test_bad_calls
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.6/nose/case.py", line 364, in setUp
    try_run(self.inst, ('setup', 'setUp'))
  File "/usr/lib/pymodules/python2.6/nose/util.py", line 487, in try_run
    return func()
  File "/home/eevans/dev/src/git/cassandra/test/system/__init__.py", line 124, 
in setUp
    self.define_schema()
  File "/home/eevans/dev/src/git/cassandra/test/system/__init__.py", line 180, 
in define_schema
    self.client.system_add_keyspace(ks)
  File 
"/home/eevans/dev/src/git/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py",
 line 1288, in system_add_keyspace
    self.send_system_add_keyspace(ks_def)
  File 
"/home/eevans/dev/src/git/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py",
 line 1295, in send_system_add_keyspace
    args.write(self._oprot)
  File 
"/home/eevans/dev/src/git/cassandra/interface/thrift/gen-py/cassandra/Cassandra.py",
 line 5745, in write
    oprot.trans.write(fastbinary.encode_binary(self, (self.__class__, 
self.thrift_spec)))
SystemError: ../Objects/dictobject.c:1562: bad argument to internal function
{noformat}

I'll probably be touch-and-go after today (traveling), but I'll try and check 
back in on this issue so that you don't have to start over with someone new.  
For me, it'd be easier if you incorporated the changes mentioned here in 
separate patch, one that applied on top of this one.

> 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.0
>
>         Attachments: 1066-3.txt, 1066-4.txt, 1066-changes-patch.txt, 
> 1066-external.patch, 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.

Reply via email to