Add a fallback database config when loading schema cache

[kytrinyx]

Summary

The schema cache defaults to loading the 'primary' database config.
However, if an app doesn't have a db config with a spec name of
'primary' the filename lookup will blow up.

This adds a fallback for this case.

Other Information

The filename for the schema cache used to be hard-coded, but Rails allows people to override the default path. In #38348 I made a change to take overrides into account, but failed to account for apps without a database config containing a spec named primary.

It turns out, at GitHub we don't have a database named primary, so even though we don't rely on this active record initializer, it blows up for us.

[tenderlove]

I thought the database configuration loading code guaranteed that one of the db configs would have a spec name of "primary". Is that not the case? Do you have a test app that can reproduce the issue?

[kytrinyx]

Do you have a test app that can reproduce the issue?

Not yet; let me make one

[kytrinyx]

I created a test app: https://github.com/kytrinyx/rails-test-app-pumpkin

The database config uses the three tier config style that we use at GitHub:
https://github.com/kytrinyx/rails-test-app-pumpkin/blob/master/config/database.yml

In the Rails console I did this:

ActiveRecord::Base.configurations.configs_for(env_name: Rails.env, spec_name: "primary")
=> nil

[tenderlove]

Got it.

Instead of loading the cache just for the "primary" connection, would it make sense to loop through each configuration, looking for schema caches, then loading those caches? Then we don't depend on a "primary" connection.

[kytrinyx]

Instead of loading the cache just for the "primary" connection, would it make sense to loop through each configuration, looking for schema caches, then loading those caches? Then we don't depend on a "primary" connection.

I think that's what this PR does, which didn't get merged: #34449

I know the multi db stuff is broken, but the change in that PR might actually be "more correct" than the current state.

Thoughts?

[tenderlove]

@kytrinyx ya, that PR does look like what we should be doing. Can you test it out, and try fixing if it's broken?

[rafaelfranca]

@casperisfine do you have opinion about this one? I think we have this problem solved in our codebase.

[kytrinyx]

I tested looping through all the configs and a bunch of tests broke, so I backed that out.

[casperisfine]

@casperisfine do you have opinion about this one? I think we have this problem solved in our codebase.

We simply don't use that code at all, and added support for multidb schema cache. Meaning each connection go grab it's schema cache in a different path (it's more complicated because many connection have similar schemas, so they share their cache as well, but it doesn't matter here).

As for Rails users in general, my worry about this PR is that by falling back to the first connection, we might load a cache that doesn't match the connection. But note that I haven't double checked wether it's actually possible or not.

IMHO It would be preferable to actually implement multi-schema cache support, e.g. one cache dump per spec_name.

IIRC I tried to implement that a few months back, but it was very hard. It might be easier now that some refactorings have been done.

[kytrinyx]

As for Rails users in general, my worry about this PR is that by falling back to the first connection, we might load a cache that doesn't match the connection.

Agreed. I pushed up a change that will simply not load a cache if we don't find a primary connection, which I think is safer.

I will start working on a new PR to see if I can work out how to load all the specs for all the connections. Last time I tried that a bunch of tests broke, so that is probably not going to be a quick fix.