connects_to e quatro pools de conexão reais

O curso de nível Pleno "Solid Queue: arquitetura de jobs" examinou onze tabelas: solid_queue_jobs, as reservas, as linhas de concorrência. Nenhuma delas é acessada pelo ApplicationRecord. Elas ficam atrás do SolidQueue::Record, outra classe base, noutra conexão. Esta aula examina essa separação no nível da conexão, antes de o resto do curso perguntar para qual banco cada conexão aponta.

Quatro classes base de model, quatro papéis

ApplicationRecord.connection_db_config.name       # => "primary"
SolidQueue::Record.connection_db_config.name       # => "queue"
SolidCache::Entry.connection_db_config.name         # => "cache"
SolidCable::Message.connection_db_config.name        # => "cable"

Esses valores vêm das classes carregadas da aplicação. O ApplicationRecord, pai de todo model que a aplicação define, Catalog::Course incluído, usa o papel primary. Solid Queue, Solid Cache e Solid Cable definem cada um a própria classe base, e cada um chama connects_to database: { writing: :queue } (ou :cache, ou :cable) em vez de manter o padrão.

São pools de conexão separados

Depois que cada classe base conecta, o gerenciador de conexões lista um pool por papel:

[ApplicationRecord, SolidQueue::Record, SolidCache::Entry, SolidCable::Message].each(&:connection)
ActiveRecord::Base.connection_handler.connection_pool_list(:writing).each do |pool|
  puts "pool: #{pool.db_config.name} -> #{pool.db_config.database}"
end

Em desenvolvimento (nomes de banco mostrados como app_development*):

pool: primary -> app_development
pool: queue -> app_development_queue
pool: cache -> app_development_cache
pool: cable -> app_development_cable

São quatro pools independentes, e não um pool servindo quatro prefixos de tabela. Cada um tira o tamanho da configuração pool: que o papel herda em config/database.yml, e em produção o papel queue define a própria, dimensionada para as threads dos workers de jobs. Um SolidQueue::Job.create! e um Catalog::Course.create! nunca disputam a mesma vaga de conexão, porque nunca dividem um pool.

Por que isto vem antes dos nomes de banco

Cada aula a seguir faz uma pergunta de ângulos diferentes: dados quatro pools separados, para quais bancos eles apontam, e a resposta muda conforme o ambiente? O trabalho desta aula era mais estreito: mostrar que a separação é real no nível da conexão, seja qual for o nome de banco que vem depois.

Pontos-chave

• SolidQueue::Record, SolidCache::Entry e SolidCable::Message declaram cada um o próprio connects_to, que resolve para "queue", "cache" e "cable", diferentes do "primary" do ApplicationRecord.
• O connection_handler.connection_pool_list mostra quatro pools independentes, um por papel, cada um dimensionado pela configuração pool: que o papel herda ou substitui.
• A separação acontece na camada de conexão do Rails, antes de qualquer pergunta sobre para qual banco físico um pool aponta.
• O resto do curso examina para onde cada pool aponta em desenvolvimento, teste e produção.