basecamp / basecamp/activerecord-tenanted
The `db:purge` rake task emits warnings and doesn't actually work
- Dominant language
- Ruby
- Stars
- 617
- Forks
- 29
- PR merge metrics
- No merged PRs in 30d
Description
The `db:purge` rake task, which is run before the test suite, will emit a harmless but annoying `NoTenantError`:
> ActiveRecord::Tenanted::NoTenantError: Cannot use an untenanted ActiveRecord::Base connection. If you have a model that inherits directly from ActiveRecord::Base, make sure to use 'subtenant_of'. In development, you may see this error if constant reloading is not being done properly. (ActiveRecord::Tenanted::NoTenantError)
This is happening because this task doesn't run with a temporary connection pool, so this needs to be fixed upstream in Rails. See some history and context at https://github.com/rails/rails/pull/46270.
My first (wrong) attempt to fix it was https://github.com/rails/rails/pull/54536. In that issue's thread, we established that the correct fix is to continuing the work started in https://github.com/rails/rails/commit/c74b2904143ce4981439acef405426bbf679a91a which (according to the commit log message) is aimed at passing a class into the adapter-specific database task classes:
- ActiveRecord::Tasks::MySQLDatabaseTasks
- ActiveRecord::Tasks::SQLiteDatabaseTasks
- ActiveRecord::Tasks::PostgreSQLDatabaseTasks
Contributor guide
Research direction
Start by reading Rails commit c74b2904143ce4981439acef405426bbf679a91a and the adapter-specific task classes ActiveRecord::Tasks::MySQLDatabaseTasks, SQLiteDatabaseTasks, and PostgreSQLDatabaseTasks. Trace how db:purge obtains its connection pool; done means the task uses a temporary connection pool and no longer emits NoTenantError or fails to purge.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rails, ruby
- Domain
- backend, database
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100