add a using_keyspace method to migrations that takes a block

[svoynow]

https://github.com/hsgubert/cassandra_migrations/issues/34

I've kept it really simple. There's now a using_keyspace method exposed to migrations that takes a block, like so:

class WithAlternateKeyspaceMigration < CassandraMigrations::Migration
  def up
    using_keyspace('alternative') do
      create_table :collection_lists, options: {compact_storage: true} do |t|
        t.uuid :id, :primary_key => true
        t.decimal :a_decimal
      end
    end
  end
end

So the overall workflow would be to:

• define all of your keyspaces/environment combinations as separate environments in cassandra.yml. You probably want to keep your main or default keyspace as just plain development or 'production`, especially if you're using the queries stuff (I'm not), so as to confuse Rails as little as possible.
• make sure to run rake cassandra:create for all of them
• but if you use using_keyspace in all your migrations for keyspaces defined in enviroments other than the standard Rails ones, you won't have to run them for each 'special' environment.

As a side note, It seems to me that if you're going to be using multiple keyspaces in one application (especially with cql-rb), you probably want to just fully qualify your table names in your queries rather than having to call USE <keyspace> all over the place. Especially since cql-rb encourages you to only have one client object per application.

[hsgubert]

Hello @svoynow-lz .

I reviewed (inspected) the code, and it seems good to me. I will not merge the pull request, as I'm leaving for @bsbodden for further review and approval.

Although I missed an inclusion of the feature in the README or in a Wiki page. I know the README file is getting big, So perhaps it is time to leave just the most important things or a "getting started" in README, and to organize more advanced uses in the wiki.

What do you all think?

[bsbodden]

Let do me a little bit of testing and I'll let you know how it goes.

[bsbodden]

We could start using the WIKI. I just tend to see WIKIs get some far out of date on projects that they seem to do more harm that good. Maybe a docs/ folder that can keep up with the versioning of the gem?

[svoynow]

I think I'm going to make another minor change that exposes configurations for other than the current environment from Config. I'll make sure it's fully backward compatible, but I think this is needed to make the rest of this feature really useful. Basically it would be nice to be able to write my own rake tasks to create / drop all my keyspaces, but actually setting Rails.env to my_special_environment (or whatever) brings along a lot of Rails baggage (Bundler groups for one thing). ActiveRecord lets you see all the db configurations, so in the spirit of doing it like AR...