Options for disable database reset, load_schema or migrate

[sergei-kucher]

Using database_reset: false, load_schema: false I don't need to wait for all migrations every time I run my tests.

[sergei-kucher]

Also I need to initialize database before combustion. This options allows combustion not to erase my initialization.

[pat]

Thanks 👍

[dsalahutdinov]

@pat, could you please release the new version of gem. Thx

[pat]

0.6.0 is now released.

[dsalahutdinov]

Thx

[jrochkind]

I don't understand where/how I'd use this option, which I think isn't mentioned in docs. Any help?

[pat]

@jrochkind I've just added some notes to the README which hopefully clarify how they can be used. I dare say such customisation isn't going to be useful for most projects though. https://github.com/pat/combustion#disabling-database-preparation

[jrochkind]

I'm interested in using ordinary migrations in my engine (which can be imported into an app that uses the engine, ordinary Rails migration style) -- this seemed like the key to that maybe? Do you think this will be possible?

Ordinary Rails engines have migrations, which a using app can import.

I want to change how tests work with combustion (to make multi-rails-version testing more feasible, for one), but don't necessarily want to change how migrations are done.

Am I on the right track? Or will local migrations work with combustion even without customizing db reset options?

[pat]

Local migrations work automatically with Combustion :) I'm using them in Gutentag, which makes use of Combustion and tests across multiple Rails and Ruby versions (with assistance from Appraisal).

[jrochkind]

Aha! But by local migrations.... my migrations will NOT be in the internal/db/migrations, but my host app db/migrations, which is how Rails engines normally wants to do it. I'll play around with it and see!

Thank you for the example to Gutentag, to look at for a model. It might even make sense to link to Gutentag in the README as a demonstration/model/example of how the author of combustion uses it.

In the past, I've actually had very little trouble just doing multi-rails version tests 'by hand'; but I should take another look at appraisal to see if does anything nifty. Generally I just make my own RAILS_VERSION env variable, and then use it in my Gemfile, etc.

[pat]

Sorry, my previous post wasn't clear. Migrations in your engine's db/migrate and spec/internal/db/migrate will both be run, after whatever is in spec/internal/db/schema.rb is applied.