Closed sergei-kucher closed 7 years ago
Also I need to initialize database before combustion. This options allows combustion not to erase my initialization.
Thanks 👍
@pat, could you please release the new version of gem. Thx
0.6.0 is now released.
Thx
I don't understand where/how I'd use this option, which I think isn't mentioned in docs. Any help?
@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
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?
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.
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.
Using
database_reset: false, load_schema: false
I don't need to wait for all migrations every time I run my tests.