Skip to content

Configurable Uniqueness Constraints

In some installations, uniqueness of the name field is not enforced, for example in Channels or Managed Objects.
Although this practice is inherently flawed, it may have originated before NOC adoption and may take significant time to resolve.
Non-unique names can also introduce complications during ETL processes, particularly when aggregating data from multiple systems.

A common workaround is appending suffixes such as #<remote id>, where <remote id> is the identifier from the external system.
However, these suffixes clutter operator dashboards and reports, distracting from actual work.

A reasonable solution is to allow the system administrator to decide—either at installation or during operation—whether to enforce name uniqueness.

Proposed Solution

Extend the configuration with a constraints section containing fields such as:

  • unique_managed_object_name (bool)
  • unique_segment_name (bool)
  • unique_channel_name (bool)

Parameter Semantics

Each constraint parameter consists of three parts:

  1. Constraint type – initially only unique is planned.
  2. Model – e.g., managed_object, segment, channel.
  3. Field – currently name.

Usage in Models

Model definitions will reference these parameters, for example:

name = StringField(..., unique=config.constraints.unique_managed_object_name, ...)

Index Management

The ensure-indexes script must be updated to:

  • Compare constraints defined in the database with those in the configuration.
  • Apply modifications if mismatches are detected.