[Pulp-dev] Single-Table Content API Changes, Performance Discussion

[Jeff Ortel]

On 11/20/18 11:31 AM, Dennis Kliban wrote:
> On Mon, Nov 19, 2018 at 6:20 PM Daniel Alley <dalley at redhat.com 
> <mailto:dalley at redhat.com>> wrote:
>
>
>     Some of the API changes that are required by single-table-content
>     would be beneficial even if we didn't go forwards with the
>     modelling changes. For instance, currently we have single
>     endpoints for each of repository_version/.../content/,
>     .../added_content/, and .../removed_content/ which mix content of
>     all types together.  This makes it impossible for clients to
>     expect the data returned to expect any particular schema.  What
>     the single-table-content does is to provide separate query urls
>     for each content type present in the repository version, which I
>     believe is a usability win for us, and it's something we could
>     implement without using any of the modelling changes.
>
>
> The current behavior of the 'content' APIs is already causing a 
> problem for our OpenAPI 2.0 schema. OpenAPI 2.0 does not support 
> polymorphic responses. We are currently tracking problem with a 
> bug[0]. The only way to resolve this problem is to provide APIs that 
> return heterogeneous types.
>
> [0] https://pulp.plan.io/issues/4052
>
>     Besides being a general update, I'd like to start a discussionto
>     understand:  is changing the Pulp 3 API so that it's organized
>     around content type URLs OK with everyone? This resolves the
>     usability issues of returning mixed types. Are there any downsides
>     with this approach?
>
>     To clarify what I mean on that last point -- by "content type
>     URLs" I mean that where you currently get back the url
>     "/pulp/api/v3/repository_version/.../content/" under the
>     "_content" field on a repoversion, you would instead get back
>     something like
>
>     { "pulp_file.filecontent":
>     "/pulp/api/v3/content/file/files/?repository_version=.. }
>
>
> I am +1 to making this change to our REST API.

+1

>
>     _______________________________________________
>     Pulp-dev mailing list
>     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>     https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
> _______________________________________________
> 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/20181126/2fa8e61c/attachment.htm>