2020-10-30 14:08:56 -04:00
---
2020-11-17 10:09:28 -05:00
stage: Enablement
group: Database
2020-11-26 01:09:20 -05: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 14:08:56 -04:00
---
2017-08-11 08:12:37 -04:00
# Verifying Database Capabilities
2019-08-12 06:29:10 -04:00
Sometimes certain bits of code may only work on a certain database
2017-08-11 08:12:37 -04:00
version. While we try to avoid such code as much as possible sometimes it is
2020-04-22 14:09:52 -04:00
necessary to add database (version) specific behavior.
2017-08-11 08:12:37 -04:00
To facilitate this we have the following methods that you can use:
2018-11-13 01:07:16 -05:00
- `Gitlab::Database.version` : returns the PostgreSQL version number as a string
2019-08-12 06:29:10 -04:00
in the format `X.Y.Z` .
2017-08-11 08:12:37 -04:00
This allows you to write code such as:
```ruby
2020-05-14 14:08:06 -04:00
if Gitlab::Database.version.to_f >= 11.7
2019-12-02 10:06:36 -05:00
run_really_fast_query
2017-08-11 08:12:37 -04:00
else
2019-12-02 10:06:36 -05:00
run_fast_query
2017-08-11 08:12:37 -04:00
end
```
2017-09-19 03:44:58 -04:00
2019-07-24 09:10:06 -04:00
## Read-only database
2017-09-19 03:44:58 -04:00
The database can be used in read-only mode. In this case we have to
make sure all GET requests don't attempt any write operations to the
database. If one of those requests wants to write to the database, it needs
to be wrapped in a `Gitlab::Database.read_only?` or `Gitlab::Database.read_write?`
guard, to make sure it doesn't for read-only databases.
We have a Rails Middleware that filters any potentially writing
operations (the CUD operations of CRUD) and prevent the user from trying
to update the database and getting a 500 error (see `Gitlab::Middleware::ReadOnly` ).