<div dir="ltr"><div>I have a design in mind for solving this problem:</div><div><br></div><div>1. Remove POST to RepositoryVersion (no general add/remove endpoint).</div><div>2. Add an endpoint to kick off an add/remove task, namespaced by plugin. ie `POST pulp/api/v3/docker/add-remove/`</div><div>   This view can be provided to all plugins by the plugin template, and will be based on the current RepositoryVersionCreate:</div><div>   <a href="https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/repository.py#L221-L258">https://github.com/pulp/pulpcore/blob/master/pulpcore/app/viewsets/repository.py#L221-L258</a></div><div>   Note: the main purpose of this view is to kick off the general add/remove task, which will be unchanged:<br></div><div>   <a href="https://github.com/pulp/pulpcore/blob/master/pulpcore/app/tasks/repository.py#L70" target="_blank">https://github.com/pulp/pulpcore/blob/master/pulpcore/app/tasks/repository.py#L70</a></div><div>3. Add an add/remove serializer to the plugin API.<br></div><div>3. Plugins needing further customization can provide their own task and subclassed serializer. <br></div><div><br></div><div>This gives the plugin writer full control over the endpoint (customizable arguments and validation), and full control over the flow (extra logic, depsolving, enforced uniqueness). It only uses the existing patterns (and existing required knowledge), but requires no work (other than using the template) for the simple case.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 3, 2019 at 2:56 PM Simon Baatz <<a href="mailto:gmbnomis@gmail.com" target="_blank">gmbnomis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jun 03, 2019 at 09:11:07AM -0400, David Davis wrote:<br>
>    @Simon I like the idea behind the repo_key solution you came up with.<br>
>    Can you be more specific around cases you think that it couldn't<br>
>    handle? I imagine that plugin writers could use properties or<br>
>    denormailzation (ie additional database columns) to solve cases where<br>
>    they need uniqueness across data that isn't in the database. In a worst<br>
>    case scenario, they can't use the pulpcore solution and just have to<br>
>    roll their own.<br>
<br>
<br>
What I wrote probably sounded too pessimistic. You are right, in<br>
most cases that should be doable.<br>
<br>
I agree that we could have a simple default solution that just<br>
requires to specify a couple of field names in the easiest case.  As you<br>
say, it should be possible use custom logic in a plugin if required.<br>
<br>
Here is the case I was thinking of that it can't handle:<br>
<br>
In pulp_file, a uniqueness constraint on "relative_path" would allow<br>
content units "a" and "a/b" to be in a repo version.<br>
<br>
However, we may want file repos to be representable on an actual file<br>
system (e.g. when exporting them as tar files).  For the repo above,<br>
this does not work, as "a" can't be a file and a directory at the<br>
same time on a standard Unix file system.<br>
<br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>