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

[Dennis Kliban]

On Tue, Nov 20, 2018 at 12:31 PM Dennis Kliban <dkliban at redhat.com> wrote:

> On Mon, Nov 19, 2018 at 6:20 PM Daniel Alley <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 discussion to
>> 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.
>

Thank you Daniel for putting together the patches[0,1] to make these
changes possible. I've had a chance to try out the Python bindings. When
using the bindings, I discovered that I could not do anything with the URLs
returned for each content type added or removed. Making the request to
those URLs requires making a call that looks like this:

api.content_file_files_list(repository_version_added=repository_version_1.href)

What if instead the API returned the number of each content type added or
removed. So a repository version response would look like:

{'base_version': None,
 'content_added': {'pulp_file.file': 4},
 'content_removed': {'pulp_file.file': 1},
 'content_summary': {'pulp_file.file': '3'},
 'created': datetime.datetime(2018, 12, 5, 23, 34, 26, 948749,
tzinfo=tzlocal()),
 'href': '/pulp/api/v3/repositories/4/versions/1/',
 'number': 1}

Thoughts?

[0] https://github.com/pulp/pulp/pull/3774
[1] https://github.com/pulp/pulp_file/pull/133


>
>>
>> _______________________________________________
>> 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/20181206/0325c1b1/attachment.htm>