Forces a DB connection to be established when running assets:precompile

[defsprite]

It looks like merely adding data_migrate to the Gemfile will force a database connection to be established during assets:clobber or assets:precompile tasks.

This is highly undesirable for Docker builds, as we have no database available unless we resort to nulldb or temporary sqlite connections during container builds.

This happens with data_migrate 8.1.1 and rails 7.0.3.1, but there might be other versions affected.

There is a small rails app at https://github.com/foxondo/data-migrate-bug to showcase the problem. Please find further details in the README there.

We've opened #221 as a proposed fix for the issue, but there might be other ways to fix this.

[ilyakatz]

Hi there, I haven't done rails in a long time, but wouldn't setting bundle dependency to not autoload solve your issue?

[defsprite]

Excellent thought! Briefly looked into this:

• Using require: false does solve the issue, but all the rake tasks will disappear.
• Using require: "data_migrate/railtie" makes the rake tasks reappear, but will bail on a rake task (db:migrate:with_data) with NameError: uninitialized constant DataMigrate::DataMigrator

I could try and restructure the gem loading (e.g. use autoload if Rails::Railtie is defined) if that route seems more appropriate to you.

What do you think?

[ilyakatz]

Thanks for the research so far! It does seems like restructure could be beneficial. But in the end of the day, I'm happy to follow your recommendation.

[dfritsch]

I recently ran up on this issue as well and was able to work around this with require: false on the gem and adding the following in my application config:

    require "data_migrate/railtie"
    ActiveSupport.on_load(:active_record) do
      require "data_migrate"
    end

I believe the railtie require needs to happen before initializers to make sure it picks up the tasks properly, but in general, we want to delay loading this gem until active record itself loads since currently loading the gem forces ActiveRecord to load which was causing some surprises configuring ActiveRecord.

For what its worth, I'm a fan of #221 which will let us just rely on this being required automatically.