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

Brian Bouterse bbouters at redhat.com
Thu Oct 19 13:57:43 UTC 2017


>From the discussion on #2873 I remember, we discussed a lot of options. We
should continue exploring those options because we haven't decided on the
long term usage. My hope is that improvements in this area will be driven
by users who can tell us more clearly about how they want to use Pulp.

We already exposed these join model models because we had to do something
for the MVP. With so many options and ways to position this usage, the
exposing of the models was the simplest option for us to create. It meets
the use cases as we've written them in the MVP (I think) and it took us
almost 0 code to do it. I think to move forward right now, we should fixup
the DELETE call and move on for now.

The ideal situation (I think) would be:

1. fixup the DELETE call and continue to expose the join model
2. release pulp3 and get users
3. have them drive improvements in this area so we can design with our
users to get this right





On Thu, Oct 19, 2017 at 8:20 AM, David Davis <daviddavis at redhat.com> wrote:

> After reading through the updating relationships section of the JSON API
> spec [1], I kind of agree with @jortel that we shouldn’t expose the join
> model unless it provides extra fields besides simply joining two models.
> Also, it might be worth adding a “content_ids” field that can be used when
> updating repositories (see [2]).
>
> By the way, I also saw there was a django-rest-framework-json-api package
> [3]. Might be worth considering.
>
> [1] http://jsonapi.org/format/#crud-updating-relationships
> [2] http://jsonapi.org/format/#crud-updating-resource-relationships
> [3] https://github.com/django-json-api/django-rest-framework-json-api
>
>
> David
>
> On Thu, Oct 19, 2017 at 12:22 AM, Michael Hrivnak <mhrivnak at redhat.com>
> wrote:
>
>>
>>
>> On Wed, Oct 18, 2017 at 4:28 PM, Dennis Kliban <dkliban at redhat.com>
>> wrote:
>>
>>> 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
>>>
>>
>> FWIW my read of #2873 is that we discussed a lot of different design
>> ideas and eventually agreed that one of them had previously been
>> implemented. I don't think we found agreement on what the design should be
>> long-term.
>>
>> --
>>
>> 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/20171019/b339ad6f/attachment.htm>


More information about the Pulp-dev mailing list