Allow different database environments

[wintersolutions]

In my projects I use combustion not only for RSpec specs but also to run the engine as an application via rackup and rack-console. It would be nice to have the option to run those commands in the development environment since this would allow to run the app and specs at the same time (and other things).

Currently the database is hardcoded to the test environment, maybe this could either check for Rails.env or something like:

Combustion.initialize! :all, database_reset: false, database_environment: :development

in config.ru.

If anybody is having the same issue, I currently use the following workaround (combustion v0.8):

In config.ru:

unless Rails.env.development?
  abort "Combustion should not be reopened in #{Rails.env} environment."
end

module Combustion
  module Databases
    class Base
      def reset
        drop
        create

        establish_connection :development
      end
    end
  end
end

module Combustion
  class Database
    class Reset
      def call
        configuration = ActiveRecord::Base.configurations['development']
        adapter = configuration['adapter'] || configuration['url'].split('://').first
        operator_class(adapter).new(configuration).reset
      end
    end
  end
end

In rails_helper.rb/spec_helper.rb:

require 'rails'

unless Rails.env.test?
  abort "Combustion should not be reopened in #{Rails.env} environment."
end

module Combustion
  class Database
    class Reset
      def call
        configuration = ActiveRecord::Base.configurations['test']
        adapter = configuration['adapter'] || configuration['url'].split('://').first
        operator_class(adapter).new(configuration).reset
      end
    end
  end
end

This allows me to run a rackup session and rspec at the same time.

[pat]

Oh, didn't see the additions to the comment until just now!

In 6d2fe4ed1b6cb3539158dfcbb8f3ea579fc1bc33 I've removed the hard-coded references to the environment - so using RAILS_ENV to dictate which env you want should hopefully do what you're after? (The default will still be test).

If that doesn't quite fit, do let me know.

[wintersolutions]

That was quick. Thanks a lot. I'll give it a spin in the next days!

That beeing said I would like to add that I was hesistant to make a PR with Rails.env as the source for the configuration since this could break the workflow of other projects that use rackup since that runs in development mode by default. Do you think this could become a issue?

[pat]

Just saw your additional thoughts now…

I just want to confirm I'm understanding your point - most people use rackup for dev environments, but by default in engines with combustion, it'd be the test env - and this difference is the concern? (Not saying you're wrong to have this concern! Just want to make sure I'm understanding it correctly)

[wintersolutions]

So until this commit the environment always defaulted to the test database. Now this behaviour would change for all projects since rackup defaults to development environment.

So before it was:

development environment & test database

Now it would be:

development environment & development database

I'm not sure how many projects would be negatively affected by this.

Also I figured out that the datbase reset always occurs on all databases, which prohibits running a rackuped application and specs at the same time.

I'm on holiday in Marocco Morocco at the moment and have very spotty internet, so my answers could take a while. But I'm going to submit a merge request in the beginning of march that would allow to run reset only on the database of the current Rails.env.

[pat]

I'll will look forward to your further thoughts/experiments - but yes, for the moment, enjoy Morocco! 😎

[wintersolutions]

@pat The code I submitted excludes default databases in Rails environments (that are not currently in use) from beeing resetted. The feature to reset other databases by default is kept. Ie. when you run in the development environment, the test db will not be reset. The database foo will tough.

I personally don't think this is a very good approach since its inconsistent and can't account for environments that developers might add later, ie. staging. But I could not come up with a better solution.

What do you think

[pat]

Closing this now that #83 is merged.