diff options
author | eileencodes <eileencodes@gmail.com> | 2019-05-31 15:14:31 -0400 |
---|---|---|
committer | eileencodes <eileencodes@gmail.com> | 2019-06-05 16:37:08 -0400 |
commit | 49b6b211a922f73d0b083e7e4d2f0a91bd44da90 (patch) | |
tree | 35f3079fb76986d75fc28034bed1590e7e365486 /guides/source/api_app.md | |
parent | ccb30615a3b6d5fd78b94fe44155310854241f6a (diff) | |
download | rails-49b6b211a922f73d0b083e7e4d2f0a91bd44da90.tar.gz rails-49b6b211a922f73d0b083e7e4d2f0a91bd44da90.tar.bz2 rails-49b6b211a922f73d0b083e7e4d2f0a91bd44da90.zip |
Move schema cache from connection to pool
This PR proposes moving the schema cache from the connection to the pool
so the connection can ask the pool for the cache. In a future PR our
goal is to be able to read the yaml file from the pool so we can get
rid of the `active_record.check_schema_cache_dump` initializer. This
will fix the issues surrounding dumping the schema cache and mulitple
databases.
Why do we want to get rid of the initializer you ask?
Well I was looking at #34449 and trying to make it work for our usecase
and it revealed A LOT of problems. There are a few issues that I will
fix in remaining PRs with SchemaMigration, but there's a big glaring
issue with this initializer.
When you have an application with multiple databases we'll need to loop
through all the configurations and set the schema cache on those
connections. The problem is on initialization we only have one
connection - the one for Ar::Base. This is fine in a single db
application but not fine in multi-db. If we follow the pattern in #34449
and establish a connection to those other dbs we will end up setting the
cache on the _connection object_ rather than on all connections that
connect for that config.
So even though we looped through the configs and assigned the cache the
cache will not be set (or will be set wrong) once the app is booted
because the connection objects after boot are _different_ than the
connection objects we assigned the cache to.
After trying many different ways to set the schema cache `@tenderlove`
and I came to the conclusion that the initializer is problematic, as is
setting the schema cache twice.
This is part 1 to move the cache to the pool so the cache can read from
the schema cache yaml file instead of setting it when initializing the
app.
To do this we have created a `NullPool` that initializes an empty cache. I
put the `get_schema_cache` and `set_schema_cache` in an `AbstractPool`
so we can share code between `ConnectionPool` and `NullPool` instead of
duplicating code.
Now we only need to set the schema_cache on the pool rather than the
connection. In `discard!` we need to unset the connection from the
schema_cache - we still want the cache just not the connection.
Diffstat (limited to 'guides/source/api_app.md')
0 files changed, 0 insertions, 0 deletions