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

[Daniel Alley]

@David Davis  The URL generation code doesn't make any assumptions, it
looks up the view name for the model and then fetches the URL associated
with that view using reverse().  It doesn't matter where the plugin writer
puts their URLs.

@Dennis Do we still want to have counts for added and removed?  It might be
useful.

On Thu, Dec 13, 2018 at 8:18 AM Dennis Kliban <dkliban at redhat.com> wrote:

> 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/87e7f6be/attachment.htm>