Also: there is nothing stopping your app from pooling connections on a per-keyspace basis. If I were writing an app where I were trying to partition on keyspace per customer, then that is what I would do.
On Sun, Jun 6, 2010 at 9:27 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > The common case is that you will have app-per-keyspace, so switching > keyspace on an active conn is an unusual thing to do. > > Optimizing the common case at the expense of the rare one is normal, > although it does sting when you're working on one of the rare ones. > > On Sun, Jun 6, 2010 at 9:10 PM, Benjamin Black <b...@b3k.us> wrote: >> Can someone enlighten me as to the purpose of set_keyspace() and the >> elimination of the keyspace args from calls? I understand there was a >> discussion of the issue before I joined the list several months ago. >> For those with several keyspaces, or many keyspaces, as when using a >> keyspace per customer, it is a huge step backwards. The change will >> require either a significant increase in the number of calls or a >> complete redesign and implementation of connection management. >> Neither is attractive. >> >> Some insight into this decision would be appreciated. >> >> >> b >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
