Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v6.2.0 incompatible with sequel-rails #456

Closed
will opened this issue Oct 29, 2019 · 6 comments · Fixed by #457
Closed

v6.2.0 incompatible with sequel-rails #456

will opened this issue Oct 29, 2019 · 6 comments · Fixed by #457

Comments

@will
Copy link

will commented Oct 29, 2019

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
Copy link
Contributor

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

@will
Copy link
Author

will commented Oct 29, 2019

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.

@will will closed this as completed Oct 29, 2019
@grzuy
Copy link
Collaborator

grzuy commented Oct 29, 2019

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 grzuy reopened this Oct 29, 2019
@grzuy
Copy link
Collaborator

grzuy commented Oct 29, 2019

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

Thanks @eliotsykes ,

I agree these are related bugs.

grzuy added a commit that referenced this issue Oct 29, 2019
…ems load order

Because of the sort algorithm rails uses to satisfy `after` and `before`
constraints, gems can have unintended effects on others. See
rails/rails@0a120a8

Prefer making rack-attack middleware idempotent instead of relying on
the load order and the contents of the middleware stack too much.

closes #452
closes #456
@will
Copy link
Author

will commented Oct 29, 2019

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
Copy link
Collaborator

grzuy commented Oct 30, 2019

Fixed in v6.2.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants