Skip to content

Explore alternative approach to multi-state boolean use in Push Rule models

Overview

In our Push Rule models (PushRule, GroupPushRule, and OrganizationPushRule), we currently implement a three-state setting system using nullable boolean columns:

true: explicitly enabled
false: explicitly disabled
NULL: inherit from global settings

This approach allows settings to cascade from global to group to project level using custom getters and setters in the model.

Current challenges

While this implementation works functionally, it presents several challenges:

  • Database semantics: Using NULL to represent "inherit" overloads the typical meaning of NULL in databases
  • Schema clarity: The database schema alone doesn't communicate the special meaning of these nullable columns
  • Query limitations: Writing SQL queries against these columns requires special NULL handling

Questions to consider

  • What is the most clear and maintainable approach to replace the current multi-state boolean?
  • What would be the migration path from the current implementation?
  • Are there performance implications to consider?
  • How would each approach affect query complexity?

Scope

This pattern appears in several settings fields across Push Rule models, including: reject_unsigned_commits, commit_committer_check, reject_non_dco_commits and deny_delete_tag

Note

This was identified during the implementation of GroupPushRule and OrganizationPushRule. We decided to maintain the existing pattern for those models to ensure a safe migration path, with the intention to revisit this design holistically in the future.