Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add a fallback database config when loading schema cache #38383
The schema cache defaults to loading the 'primary' database config.
This adds a fallback for this case.
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
It turns out, at GitHub we don't have a database named
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.
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:
In the Rails console I did this:
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.
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
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.
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.
Hopefully third time's a charm. Originally, the schema cache initializer railtie was loading the 'schema_cache.yml' file by hard-coding the path. Since it's possible to override the schema cache path either by providing an ENV variable, or by adding a configuration entry to the database.yml config file, this means that we could potentially end up not loading a cache that is configured to use a non-default file. The first attempt at fixing this (rails#38348) assumed that the db config must contain a spec named 'primary'. This is not the case. A second attempt at fixing this (rails#38383) bailed if no db config was found. This however, means that for an app without a db config named 'primary', we would not be attempting to load a schema cache at all, even if they were using the default schema cache path. Instead of bailing, here we go get the filename, passing a 'nil' for the schema_cache_path, which will fall back to the default path.