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

David Davis daviddavis at redhat.com
Thu Dec 13 12:32:59 UTC 2018


How are these URLs being populated? What if the plugin writer puts her
content URLs at a different place like /pulp_rpm/content/packages or
something?

David


On Wed, Dec 12, 2018 at 8:38 PM Dana Walker <dawalker at redhat.com> wrote:

> I agree that the "human usable" route makes sense.
>
> We want to make this as easy to use as possible.
>
> --Dana
>
> Dana Walker
>
> Associate Software Engineer
>
> Red Hat
>
> <https://www.redhat.com>
> <https://red.ht/sig>
>
>
> 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
>>
> _______________________________________________
> 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/d042f0c2/attachment.htm>


More information about the Pulp-dev mailing list