Multiple keyspace support - request for comments

[svoynow]

It would be nice to have support for multiple keyspaces within a Rails environment configuration (rather than having non-standard environments to support additional keyspaces). But I'm not sure a) if anybody else feels this need. b) what the right way would be to implement it. I want to both keep it relatively simple implementation-wise, and not make life any more complicated for people who don't need this feature

Here's what I've got so far:

Keep specifying a single keyspace in cassandra.yml and treat that as the "default" keyspace. Expose create_keyspace and use(keyspace) methods to migrations. So it's the responsibility of the migration author to create any additional keyspaces they need, and call use before any operations they want to perform on entities in those keyspaces. Seem a bit error prone on that end, but it's the simplest thing to implement. Another thing I don't like about this approach is that the rake drop task wouldn't know anything about the non-default keyspaces. Alternatively, to remedy that issue we could add support for multiple keyspaces in cassandra.yml with some way of specifying which one was the default (maybe just have it be the first one in the list so it's transparent to users who don't care) Another possibility rather than explicitly call a use method before table/column operations in migrations to use a non-default keyspace, we could make it an option for those operations. i.e. create table :users, keyspace: :special do etc. If not provided would use the default.

So I guess there are two questions here:

a) support for multiple keyspaces in cassandra.yml (with default), yea or nay? b) explicit call to use in migrations or keyspace as (optional) option for table and column operations?

Any thoughts? Preferences? Comments? Totally different proposal? I'll probably just start working on one of these approaches. But any feedback that makes it more likely to eventually get pulled would be appreciated.

Cheers!

[hsgubert]

Nice initiative @svoynow-lz!

I never worked with multiple keyspaces (as I never worked with multiple databases for the same rails application). My first suggestion would be to consider the way it is done with ActiveModel. Certanly those guy gave a lot of thought on the subject already.

Independently of how the rails core team solved this issue in ActiveModel, the second options seems very good. I don't see any downsides, unless that it is probably a little more work to implement.

[svoynow]

The ActiveRecord way to do it would to just have an environment in cassandra.yml for each keyspace, production_foo, production_bar etc. Which just means you need to run the create, drop, migrate etc rake tasks for each of these. Maybe that's actually totally satisfactory. All we'd be missing is an equivalent of establish_connection that we could use in migrations. Just a way to specify keyspace to use. Certainly much less code to write.

Sent from my iPhone

On May 22, 2014, at 3:48 AM, hsgubert notifications@github.com wrote:

Nice initiative @svoynow-lz!

I never worked with multiple keyspaces (as I never worked with multiple databases for the same rails application). My first suggestion would be to consider the way it is done with ActiveModel. Certanly those guy gave a lot of thought on the subject already.

Independently of how the rails core team solved this issue in ActiveModel, the second options seems very good. I don't see any downsides, unless that it is probably a little more work to implement.

— Reply to this email directly or view it on GitHub.

[bsbodden]

I agree that doing it the ActiveRecord way would make usage much familiar to the Rails community. I've also been playing with doing multi-tenancy with C* (e.g. upon account creation I make account specific key spaces) for which would be nice to have a nice programmatic API for in App migration usage. Maybe this is a completely different topic but something to keep in mind while implementing the multiple keyspace support)