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

[Dana Walker]

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





On Wed, Dec 12, 2018 at 5:51 PM Brian Bouterse  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  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  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@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> ___
>> Pulp-dev mailing list
>> Pulp-dev@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Brian Bouterse]

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  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  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@redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Daniel Alley]

>
> 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  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@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

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

[Jeff Ortel]

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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev