Skip to content

How do we migrate ContributorUUID to handle new instances? #511

Open

Description

@MoralCode

ContributorUUID is currently hardcoded as a custom UUID format containing a contributors unique id on the platform as well as a platform identifier.

We should migrate this to a colon-delimited string thats easier to deal with, similer to what #312 plans to do with repo_src_id.

Problems:

  • are these IDs being stored as UUID types? will we lose performance if we switch to strings?
  • these identifiers are used as foreign keys

Activity

  1. MoralCode commented on Oct 4, 2026

    @MoralCode
    ContributorAuthor

    Sonnet 4.6 Medium says:
    data.contributors.cntrb_id is referenced as a FK by at least these tables:

    Table Column Behavior
    contributor_repo cntrb_id RESTRICT / CASCADE
    contributors_aliases cntrb_id CASCADE (deferred)
    commits (via cmt_ght_author_id) FK
    issues cntrb_id, reporter_id —
    message cntrb_id CASCADE
    pull_requests pr_augur_contributor_id RESTRICT
    issue_assignees cntrb_id —
    issue_events cntrb_id RESTRICT
    pull_request_commits pr_cmt_author_cntrb_id CASCADE
    pull_request_events cntrb_id —
    pull_request_meta cntrb_id —
    pull_request_repo pr_cntrb_id —
    pull_request_reviewers cntrb_id CASCADE
    pull_request_reviews cntrb_id RESTRICT
  2. MoralCode commented on Oct 4, 2026

    @MoralCode
    ContributorAuthor

    i think its just way too infeasible to switch away from this UUID type given how much stuff uses it.

    It also already encodes the same information we would use anyway (instance id + contributor unique id on that instance), just in a slightly more opaque, but numeric-like format that can be more easily queried in postgres

  3. added
    needs-planIssues that need a plan to be approved by maintainers before implementation
    on Oct 8, 2026
  4. MoralCode commented on Oct 12, 2026

    @MoralCode
    ContributorAuthor

    In addition to the hardcoding, this identifier is a privacy/PII issue and we should have the ability to delete it if needed

    IMO we should use an autoincrement integer internally, and have this id in more of a contributor concordances style format

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-planIssues that need a plan to be approved by maintainers before implementationpending-maintainersWaiting for maintainer decision on something

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions