On Wed, Jul 18, 2012 at 10:27 AM, Douglas Muth <doug.m...@gmail.com> wrote: > Even though keyspace "test1" had a replication_factor of 1 to start > with, each of the above UPDATE KEYSPACE commands caused a new UUID to > be generated for the schema, which I assume is normal and expected.
I believe the actual issue you have is "stuck schema for this keyspace," not anything to do with replication factor. To test this, try adding a ColumnFamily and see if it works. I bet it won't. There are anecdotal reports in the 1.0.8-1.1.5 timeframe of this happening. One of the causes is the one aaron pasted, but I do not believe that is the only cause of this edge case. As far as I know, however, there is no JIRA ticket open for "stuck schema for keyspace" ... perhaps you might want to look for and/or open one? =Rob -- =Robert Coli AIM>ALK - rc...@palominodb.com YAHOO - rcoli.palominob SKYPE - rcoli_palominodb
