[Pulp-dev] Many-to-many joins in the API

[Dennis Kliban]

Exposing the RepoContent model via REST API leaves us with the most
flexibility in the future. We decided on this design in issue 2873[0].

[0] https://pulp.plan.io/issues/2873

On Wed, Oct 18, 2017 at 1:38 PM, Michael Hrivnak <mhrivnak at redhat.com>
wrote:

> Whenever we get to versioning repositories, that will have a big impact on
> the issues you're raising. Regardless of how exactly a user causes content
> to be added or removed from a repo, the main result of the operation will
> be the creation of a new repo version. For example, a sync task would
> create a new version as its output, and that version would reference the
> creation and removal of relationships to content.
>
> From a REST standpoint, that changes what expectations we need to meet.
> For one, the RepositoryContent model will change, and we probably won't
> want to allow users to directly create/update/delete those entries, on the
> principle that a repo version is immutable. If the user wants to add or
> remove content from a repo, the output must always be a new version.
>
> POSTing and DELETing to either a relationship endpoint or a content
> endpoint isn't a great fit either. If we had a path "
> /api/v3/repositories/<repo-id>/content/", it would only be a shortcut to
> the set of content in the repo's current version. A user should not expect
> to be able to change a content set directly, so giving them write access
> there could be misleading.
>
> A simple option could be to allow a POST to a repo version endpoint. If a
> user did a GET on "/api/v3/repositories/<repo-id>/versions/<num>/", they
> should probably get a representation that includes what content was added
> and removed by that version. We could allow them to POST a similar
> representation to  "/api/v3/repositories/<repo-id>/versions/", which
> would create a new version that makes the desired additions and removals.
> From a REST standpoint, I think that's the most natural way to facilitate
> arbitrary adding and removing of content given a model that includes repo
> versions.
>
> That approach could also solve our upload problem, where we don't want 100
> uploads to create 100 repo versions. A user could create 100 new content
> units via upload, and then associate them to a repo in one operation.
>
> Thoughts on that?
>
> On Wed, Oct 18, 2017 at 12:45 PM, David Davis <daviddavis at redhat.com>
> wrote:
>
>> Working on issue #3073 [1], there was a discussion that came up about how
>> to best handle updating many-to-many joins in the API. We currently have a
>> many-to-many relationship between repositories and contents which is
>> handled by a RepositoryContent model. The api for this model is at
>> /api/v3/repositorycontents/ (more info here [2]). But we also have an API
>> already at /api/v3/repository/<repo-id>/content as well but it currently
>> only lists the contents for a repository.
>>
>> I think there are two options for supporting many-to-many joins in the
>> API. First, we could continue to expose the join model and have routes like:
>>
>> POST /api/v3/repositorycontents/ (which takes a repo id and content id)
>> DELETE /api/v3/repositorycontents/<repo-content-id>/
>>
>> We would have to start exposing the repo content id in the api to get
>> this second link working.
>>
>> However, alternatively, we could use a nested route to handle
>> adding/removing repo contents:
>>
>> POST /api/v3/repositories/<repo-id>/content/ (which takes a content id)
>> DELETE /api/v3/repositories/<repo-id>/content/<content-id>/
>>
>> This second scheme would essentially hide the RepositoryContent model
>> from API users. I am not sure if that’s a good thing or a bad thing.
>>
>> Thoughts?
>>
>> [1] https://pulp.plan.io/issues/3073
>> [2] https://pulp.plan.io/issues/2873
>>
>> David
>>
>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
>>
>
>
> --
>
> Michael Hrivnak
>
> Principal Software Engineer, RHCE
>
> Red Hat
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171018/e995694b/attachment.htm>