Add per-table concurrent timeout overrides

[mathyoudawson]

Summary

• Adds an optional table_overrides config hash to register_database, letting apps override concurrent_lock_timeout/concurrent_statement_timeout for specific tables (e.g. a huge payments table needing a longer statement timeout than the database-wide default).
• Falls back to the database-level value for any table (or key) not listed. Per-migration set_lock_timeout/set_statement_timeout still takes precedence over both.
• Fully backward compatible: table_overrides defaults to {}, no behaviour changes for existing configs.

Nandi.configure do |config|
  config.register_database(:primary,
    concurrent_statement_timeout: 600_000,   # 10 min database-wide default
    table_overrides: {
      payments: { concurrent_statement_timeout: 1_800_000 }, # 30 min for payments
    })
end

Bumps version to 3.2.0.

Test plan

• bundle exec rspec — 447 examples, 0 failures
• bundle exec rubocop — 0 offenses
• New specs added for MultiDatabase::Database, Config, and Migration covering: override present/absent, partial-key overrides, string/symbol table names, per-migration override precedence, and multi-database database_name + table resolution together

🤖 Generated with Claude Code

[yermold]

Nice! Left a couple questions.

[yermold]

config doesn't allow non-sym keys for other params, why would we want to be so forgiving in this case?

[mathyoudawson]

IMO the table_overrides config is a special because the keys are table names. Nandi already handles table names as strings or symbols in DB instructions (e.g. add_index :table_name and add_index "table_name").

It's conceivable that someone might assume that this config behaves the same way. By silently ignoring strings we would use the default timeout.

[yermold]

Okay, then we could also ensure that string table-name inputs are supported by using @table_overrides = (config[:table_overrides] || {}).with_indifferent_access, so we don't silently ignore if someone accesses config using a string table name.

[mathyoudawson]

This would cause the inner hash to be tolerant of string keys too. So table_overrides: { payments: { "concurrent_statement_timeout" => 600_000 } } would be supported.

In this case I just want to handle table names as strings rather than changing the behaviour of how inner options can be configured.

[yermold]

with_indifferent_access is not deep by default

[mathyoudawson]

It is deep by default. I tested this in a rails console

{ payments: { "inner_key" => "ok" } }.with_indifferent_access[:payments][:inner_key]
=> "ok"

[yermold]

That's surprising. I expected it to operate on a single level like the other hash helpers. Good to know :)

[yermold]

Shouldn't these specs live in the main migration spec file?

[mathyoudawson]

These tests are testing different things in different environments.

The migration specs are effectively an integration test. The specs that were added checks that the table overrides work with the rest of the migration logic.

The multi_database specs are testing the actual override timeout calculation logic in isolation.

[yermold]

Ok, I was confused that there’s logic and specs specifically for the “multi-database” case, but nothing for the “single-database” use case. Then I realised that the multi-database code superseded the single-database setup, so everything in Nandi is now multi-database by default.

[yermold]

LGTM