Skip to content

Cells: Handle unique index gitlab_main_cell.organizations.unique_organizations_on_path_case_insensitive

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

We are reaching out from the sectiontenant scale devopsruntime, and we have noticed a problematic Unique index unique_organizations_on_path_case_insensitive on the organizations table.

As part of Protocells, we need to ensure that this index is still unique.

With multiple GitLab instances and separate databases, this unique index will no longer be unique and may cause issues when data needs to be transferred between cells or when cluster-wide uniqueness is required but cannot be enforced by the index.

For all the unique indexes, we have the following options:

Options for Resolution

Option A: Scope Down the Index 🔧

  • Update the index to include the sharding_key ({"id"=>"organizations"}) as one of the columns
  • This ensures the constraint works within each cell's scope
  • Most common solution for indexes that can be scoped to organizational boundaries
  • When to choose: If the uniqueness can be maintained within the cell boundary

Option B: Claim the Index 🏷️

  • If any column in the index is claimed through the Topology Service, it ensures global uniqueness
  • Suitable when one of the indexed columns needs cluster-wide uniqueness enforcement
  • Requires integration with the Claim Service
  • When to choose: If global uniqueness across all cells is required; example username, email, etc.

Option C: Do After Protocells ⏳

  • Defer this index until after Protocells implementation
  • Suitable for indexes on columns with low collision probability (UUIDs, tokens, etc.)
  • Can be addressed in a later phase due to built-in randomness
  • When to choose: If the column has sufficient entropy to avoid conflicts

Index Details

  • Schema: gitlab_main_cell
  • Table: organizations
  • Index Name: unique_organizations_on_path_case_insensitive
  • Index Columns: lower(path)
  • Sharding Key: {"id"=>"organizations"}

Current Analysis

Decision from our analysis: Claim

Notes: Since the path is going to be claimed, the index doesn't need to change.

Next Steps

Please review the options above and choose the most appropriate approach for this index:

  • Option A: Scope down the index (add sharding key to columns)
  • Option B: Claim the index (use Topology Service)
  • Option C: Do after Protocells (defer due to low collision risk)

Resources

Questions?

If you have any questions about these options or need clarification on the cells architecture requirements, please feel free to reach out to us in #f_protocells or comment on this issue.

Edited by 🤖 GitLab Bot 🤖