Project

Profile

Help

Story #1446

closed

As a plugin writer, I can specify a uniqueness constraint on the RepoAssociation objects that involve my Units

Added by rbarlow over 8 years ago. Updated almost 4 years ago.

Status:
CLOSED - WONTFIX
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:

Description

There are a few use cases where plugin authors have added repo_ids to their Units to establish uniqueness, such as PackageGroups PackageCategories, and Tags (Docker). I am more familiar with the latter, so I will describe what is happening, and then what Pulp could do that would be superior: Docker Tags contain a repo_id, a tag name, and a Docker Manifest digest. They make the repo_id and tag name have a uniqueness constraint so that a repository can only have that name one time.

It would be better if the Docker Tag model could express a repository uniqueness constraint with a list of fields that should be unique in the repository. This way, Pulp could establish the database uniqueness constraint on the RepoAssociation models that get created when the Tag is added to a repository. It would be less "hacky" than what the Tag unit has done to establish this uniqueness for itself, because it doesn't make sense for the object itself to have a repo_id field. For example, one problem with the current approach is that an association is really a copy - if a Docker tag is copied from one repository to another, a new unit is created in the destination repo with the same name and digest, but the repo_id field must be altered to match the destination repo_id.

If Redmine had a "Nice to have" tag I'd pick that for this ticket. It's not strictly necessary but I think it would be a better model.

Also available in: Atom PDF