Question regarding single database configuration

[rnestler]

For a small app running on Heroku I want to use solid_queue (solid_cable and solid_cache as well) with just a single postgres database.

The guide here reccommends to

Running Solid Queue in a separate database is recommended, but it's also possible to use one single database for both the app and the queue. Just follow these steps:

1. Copy the contents of db/queue_schema.rb into a normal migration and delete db/queue_schema.rb
2. Remove config.solid_queue.connects_to from production.rb
3. Migrate your database. You are ready to run bin/jobs

You won't have multiple databases, so database.yml doesn't need to have primary and queue database.

In other resources (https://briancasel.gitbook.io/cheatsheet/rails-1/setup-solid-queue-cable-cache-in-rails-8-to-share-a-single-database) it is recommended to configure 4 different databases to actually use the same database:

production:
  primary: &primary_production
    <<: *default
    url: <%= ENV["DATABASE_URL"] %>
  cache:
    <<: *primary_production
  queue:
    <<: *primary_production
  cable:
    <<: *primary_production

But this leads to very strange behavior, such as rails db:migrate creating three identical schemas: db/cable_schema.rb db/cache_schema.rb db/queue_schema.rb db/schema.rb.

So my questions is: When going with the instructions form this repository shouldn't I still have a connects_to call in production.rb to ensure that solid_queue uses it's own connection pool? So replacing

config.solid_queue.connects_to = { database: { writing: :queue } }

with

config.solid_queue.connects_to = { database: { writing: :primary } }

[rosa]

Both approaches work, either using only the primary database or having the four different DBs in database.yml, with their duplicated schema files as you saw.

About the connects_to call, it depends on what you want. Solid Queue would work just fine using the same connection pool as your app. You can have it use its own connection pool if you want to ensure enqueuing jobs uses a different connection pool so that you don't accidentally rely on jobs being enqueued inside transactions and not actually enqueued until the transaction commits, although you can also use Rails's enqueue_after_transaction_commit to ensure that 🤔

[rnestler]

Thanks for your fast response!

In my opinion just having the connects_to call's makes it very clear that we are actually using the same DB but separate connections. Also it is less confusing to not have multiple identical schemas and having db related commands behave as if there were multiple databases:

$ rails db:create
Created database 'foobar_development'
Database 'foobar_development' already exists
Database 'foobar_development' already exists
Database 'foobar_development' already exists
Created database 'foobar_test'

Solid Queue would work just fine using the same connection pool as your app.

Do you have an opinion regarding Solid Cache and Solid Cable regarding that? Or should I open similar issues on these GitHub projects?

[rosa]

Yeah, I think having connects_to calls is very clear! 👍

I think the same would apply to Solid Cache and Solid Cable, although I'm not familiar with Solid Cable internals.

[rnestler]

I think the same would apply to Solid Cache and Solid Cable, although I'm not familiar with Solid Cable internals.

An old version of the solid_cache README mentions

The default installation of Solid Cache expects a database named cache in database.yml. It should have it's own connection pool to avoid mixing cache queries in other transactions.

The latest README doesn't mention running on a single database since rails/solid_cache#202

So I guess at least for solid_cache it's better to run with it's own connection pool.