2020-10-30 18:08:56 +00:00
---
stage: none
group: unassigned
2020-11-26 06:09:20 +00:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-10-30 18:08:56 +00:00
---
2020-03-02 12:07:57 +00:00
# Rails initializers
By default, Rails loads Zeitwerk after the initializers in `config/initializers` are loaded.
Autoloading before Zeitwerk is loaded is now deprecated but because we use a lot of autoloaded
constants in our initializers, we had to move the loading of Zeitwerk earlier than these
initializers.
A side-effect of this is that in the initializers, `config.autoload_paths` is already frozen.
To run an initializer before Zeitwerk is loaded, you need put them in `config/initializers_before_autoloader` .
Ruby files in this folder are loaded in alphabetical order just like the default Rails initializers.
Some examples where you would need to do this are:
1. Modifying Rails' `config.autoload_paths`
2021-07-19 18:08:23 +00:00
1. Changing configuration that Zeitwerk uses, for example, inflections
2022-04-20 18:11:54 +00:00
## Database connections in initializers
Ideally, database connections are not opened from Rails initializers. Opening a
2022-05-24 12:09:04 +00:00
database connection (for example, checking the database exists, or making a database
2022-04-20 18:11:54 +00:00
query) from an initializer means that tasks like `db:drop` , and
`db:test:prepare` will fail because an active session prevents the database from
being dropped.
To help detect when database connections are opened from initializers, we now
2022-06-06 18:09:02 +00:00
warn in `STDERR` . For example:
2022-04-20 18:11:54 +00:00
```shell
DEPRECATION WARNING: Database connection should not be called during initializers (called from block in < module:HasVariable > at app/models/concerns/ci/has_variable.rb:22)
```
If you wish to print out the full backtrace, set the
`DEBUG_INITIALIZER_CONNECTIONS` environment variable.
