v6.2.0 incompatible with sequel-rails

[will]

v6.1.0 and previous were okay, but v6.2.0 is doing something that is causing my models to be loaded before sequel-rails sets up the database connection resulting in

Sequel::Error:
  No database associated with Sequel::Model: have you called Sequel.connect or Sequel::Model.db= ?

I've spent the last while trying to figure out how to get things loaded in the same order as before, but I've run into only dead ends.

It appears the problem happens in both rails 5.2.3 and rails 6.0.0.

Does anyone have any clues?

[eliotsykes]

Load order bugs could be due to the initializer discussed in #452

[will]

I finally found a solution by requering the sequel rails railtie right after boot in config/application.rb .

require File.expand_path("../boot", __FILE__)

require "sequel_rails/railtie" # early load this manually due to https://github.com/kickstarter/rack-attack/issues/456

I tried to mess with Rails::Application.config.railties_order , but neither putting sequel rails first, nor rack-attack last made any difference.

I'm going to close this, just putting this info down in case others come later searching.

[grzuy]

Hi @will,

Thank you for reporting this.

I was able to at least reproduce the fact that rack-attack affects the initialization order of sequel-rails in respect to config/initializers/* loading.

See the following test app: https://github.com/grzuy/test_app_rack_attack_456/commits/master. In particular this commit: grzuy/test_app_rack_attack_456@ac8430f.

I recommend temporarily moving gem 'rack-attack' to the bottom of the Gemfile if possible, until we release a fix for this.

[grzuy]

Load order bugs could be due to the initializer discussed in #452

Thanks @eliotsykes ,

I agree these are related bugs.

[will]

I'll have to wait until tomorrow to check for real, but I'm super surprised that the order in the gemfile determines load order!

edit: it did also work by moving rack-attack to the bottom of the gemfile. I think I'll keep my manual require for the time being since that seems… more normal to me. Thanks for letting me know about the other method though.

[grzuy]

Fixed in v6.2.1.