cpoms / innkeeper Goto Github PK

I'm not sure what the best approach would be to handle Sidekiq support for Innkeeper, but happy to help with this.

@mikecmpbll: I am happy to clone the latest version of apartment-sidekiq gem, rename to innkeeper-sidekiq and open a PR to your fork of apartment-sidekiq, but wanted to see if perhaps there's a better approach to avoid 100% duplication of the underlying code. Obviously innkeeper is a significant re-write of Apartment, but in the case of apartment-sidekiq, the code would remain identical.

I keep running into certain issues that look like they might have been resolved in the current Apartment repo since this codebase was originally forked from the Apartment repo.

I have tried patching them as I run into them, but was wondering if there are any plans to do some kind of a "rebase" against the current Apartment repo. I know there were quite a few issues in the other repo that this repo probably addresses and vice versa, so perhaps there's a way to let people know about the existence of this project.

On a related note, are there some obvious incompatibilities with Rails 6 here? I'm running into some weird problems (for example, data is being silently "lost" - it looks like it saves in the console but actually is not saved at all). Finding it quite challenging to troubleshoot.

Hi, I was trying to install innkeeper gem for Multidb server feature with rails. while installing, i am getting below error. Please suggest the fix without effecting the current gems dependent on public suffix

Bundler could not find compatible versions for gem "public_suffix":
In snapshot (Gemfile.lock):
public_suffix (= 4.0.3)

In Gemfile:
carrierwave-azure_rm was resolved to 0.1.2, which depends on
carrierwave was resolved to 2.0.2, which depends on
addressable (~> 2.6) was resolved to 2.7.0, which depends on
public_suffix (>= 2.0.2, < 5.0)

  innkeeper was resolved to 0.1.0, which depends on
  public_suffix (~> 2.0.5)

Anyone using in real production environment?

When Passenger spawns a new app process it now calls establish_connection on ActiveRecord::Base, which causes connection_specification_name to be set back to :primary after we've already set it to nil in the main process. We depend on it being nil so that our custom switching code can take precedence.

With this change, connection_specification_name will always be :primary on spawned processes thus not allowing them to connect to other hosts (or any hosts, if your :primary config is not a production config)

It should be apparent which tenant a log line relates to