[Idea] Ignore migrations from non-supported adapters

[jenskdsgn]

Hey,

first of all thanks for this helpful gem! In my current situation I am trying to add a second database as part of Rails' multi database configuration. The primary db will be postgres and secondary clickhouse, both databases will be owned by the rails app including migrations. The current behaviour from looking at strong_migration's code, it would pick the AbstractAdapter and would raise an error on setting the timeout here.

So the two options I am seeing here is

1. Create a clickhouse adapter and add it to your code base
2. Ignore migrations from databases with unsupported adapters

Since the support of multiple databases on Rails, it would be nice to have an option to pick on which databases to apply this gem.

[ankane]

Hi @jenskdsgn, thanks for the suggestion! Added a warning for unsupported adapters and an option to ignore databases in the ignore branch, but want to figure out a better name (or pattern) before merging.

[jenskdsgn]

Wow. Thanks for the prompt reply. I'll test this and let you know if it works!

[jenskdsgn]

Ok, I had the time to check it. Unfortunately when ignoring the database, the checks are ignored, which is good, however the migration didn't execute either.

I think the offending line is here:

https://github.com/ankane/strong_migrations/compare/ignore#diff-70c919b24b6428e59eef896cbbd7f567bde86e86d5649af3dc6330fbe9c974c4R31

I believe it should be:

return yield if !enabled?

if I understand it correct, the checker class executes the migration in the block after the check. If you guard the perform with enabled it won't execute the block, which is not the expected behavior. I want to disable the strong migration check and not the whole migration.

[lucas-jt]

Hello @ankane 👋

Would it be possible to merge the changes from the ignore branch into master? This is an optional configuration, so it wouldn't change the gem's behavior.

I need this functionality because we are also using ClickHouse. As the ignore branch is outdated, we plan to create and maintain an internal fork.

Is there any specific reason for not adding this to master?