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

[Dennis Kliban]

Let's continue with hte original proposal and keep the URLs.

On Wed, Dec 12, 2018 at 5:51 PM Brian Bouterse <bbouters at redhat.com> wrote:

> I commented on the PR that I think we should include the URLs and here's
> the reasoning:
> https://github.com/pulp/pulp/pull/3774#issuecomment-446633354
>
> On Wed, Dec 12, 2018 at 5:29 PM Daniel Alley <dalley at redhat.com> wrote:
>
>> Just thought of something.  The URLs for specific content types are at
>>> the discretion of the plugin writer so now I'm not convinced the user
>>> has a way to reliably construct the URLs themselves.
>>
>>
>> Yup, this is my view.  The counterargument Dennis has been making is that
>> the user could either A) use the live API docs to find out what URL to hit,
>> B) find it in the hosted docs, or C) use the bindings generated from the
>> schema, the name of the function is documented and you don't need to care
>> about the URL.
>>
>> I suppose it depends on exactly how frequently users actually need to
>> view/search on the content present in a repository version.  If it's a rare
>> need, then maybe that extra friction is OK.  If it is common, it could be a
>> pain point -- or perhaps people will just memorize all the endpoints they
>> need to use and it won't be a big deal, I don't really know.
>>
>>
>> On Wed, Dec 12, 2018 at 1:14 PM Jeff Ortel <jortel at redhat.com> wrote:
>>
>>> On 12/10/18 1:06 PM, Jeff Ortel wrote:
>>> > +1 to counts instead of URLs.  The URLs are documented and can be
>>> > constructed to listing them on the serialized version does not seem to
>>> > add much value.  The counts would likely provide more useful
>>> > information and consistent with the summary counts.
>>>
>>> Just thought of something.  The URLs for specific content types are at
>>> the discretion of the plugin writer so now I'm not convinced the user
>>> has a way to reliably construct the URLs themselves.
>>>
>>> >
>>> > On 12/7/18 1:30 PM, Dennis Kliban wrote:
>>> >> 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?
>>> >
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> 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
>>
> _______________________________________________
> 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/20181213/f180cbd4/attachment.htm>