<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=14475) </details> <!--IssueSummary end--> In past we had some errors with application settings. People create migrations to add new column to `application_settings` table, and sometimes forget about default value, sometimes it is difficult or impossible to add default value to database column. Currently we do not have mechanism to fallback to default value configured in `create_from_defaults` method, therefore we sometimes run into unexpected `nil` values, which cause exceptions. We should improve `ApplicationSetting` model to prevent such problems in the future. We can consider few approaches, like using default setting if database entry is `nil` (we can override `_read_attribute` to achieve this), or we can go for more object oriented design, where each setting has a separate class, that takes persistence model in an initializer and implements it's own default values (this is solution that seems interesting for me). Another ideas appreciated. /cc @rspeicher @DouweM @ayufan