feat: prevent duplicates [CM-2320]

[ulemons]

✍️ Proposed Changes

What:

• Prevent assigning the same repository to multiple insightsProjects and segments.
• Fix a potential bug in SegmentRepository.mappedRepos, which was not accounting for the deletedAt field.

How:

1. New table: segmentRepositories — stores the association between each repository and its corresponding segment with a UNIQUE INDEX on the combination in order to prevent multiple assosiations.
2. when updating an InsightsProject a new function upsertSegmentRepositories is called. This will upsert in bulk all the new repo associated.
3. once the new repos are added the function softDeleteMissingSegmentRepositories is called, which set the deletedAt on the repo which are not anymore related to the project

Notes:

This approach may introduce some duplication of data already available in the githubRepos and gitlabRepos tables. However, since repository data is derived from the integrations.settings field too, enforcing database-level constraints directly on those tables is not feasible. Hence, this duplication is a necessary trade-off to maintain data integrity.

🔗 colses: CM-2320

Checklist ✅

• Label appropriately with Feature, Improvement, or Bug.

[github-actions]

PR titles must follow Conventional Commits. Love from, Your reviewers ❤️.

Conventional Commits FTW!

[themarolt]

Hm so far we didn't use triggers or functions or procedures in the db itself so I'm wondering if it would be better to have this logic in the code itself?

[ulemons]

I was thinking of doing it this way for performance reasons. We can also implement it in code and see how it performs.

[themarolt]

Ye I would do that instead of triggers as it hides somewhat the logic. I mean if we were using this before I would let it be but if it's gonna be the only function we have in the db with such logic it will be hidden in a sense where people won't expect to find the logic here :)

[ulemons]

that makes perfectly sense, thanks!

[borfast]

Shouldn't we add the unique index for every row, even if it's deleted, to avoid issues in case we ever remove the soft deleted marker?

[ulemons]

I added this constraint to keep track of deletions. If we use a unique index for every row, I guess we must use hard deletion. If this is the case I think we can go directly with hard deletion

[borfast]

We don't have to have another unique index for each row because we already have the primary key on the repository and segmentId, which already makes them unique. Or am I missing something?

[borfast]

Approved. 👍 Just one question that isn't critical.