[Pulp-dev] Revisit: sync modes
I'm not convinced that /named/ sync mode is a good approach. I doubt it will ever be anything besides (additive|mirror) which really boils down to mirror (or not). Perhaps the reasoning behind a /named/ mode is that it is potentially more extensible in that the API won't be impacted when a new mode is needed. The main problem with this approach is that the mode names are validated and interpreted in multiple places. Adding another mode will require coordinated changes in both the core and most plugins. Generally, I'm an advocate of named things like /modes/ and /policies/ but given the orthogonal nature of the two modes we currently support _and_ that no /real/ or anticipated use cases for additional modes are known, I'm not convinced it's a good fit. Are there any /real/ or anticipated use cases I'm missing? I propose we replace the (str)sync_mode="" with (bool)mirror=False anywhere stored or passed. Are there any /real/ or anticipated use cases I'm missing? Thoughts? ___ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] Plan to handle ids and hrefs
Yea, the names here are in terms of the names we use today and are subject
to the outcome of the field naming thread.
David
On Wed, Aug 8, 2018 at 12:17 PM Daniel Alley wrote:
> As per the other discussion thread, I assume the names will actually be
> _id, _type, _href?
>
> Errata have both "id" and "type" fields, so if we're going to attempt to
> keep the Pulp metadata field names out of the way of Content field names,
> we need to do it for all of them.
>
> On Wed, Aug 8, 2018 at 12:02 PM, David Davis
> wrote:
>
>> After recent meetings with stakeholders, we've arrived at a solution on
>> how to handle ids and hrefs in the Pulp 3 API. The plan is to stop
>> accepting hrefs for fields to instead rely solely on IDs. Hrefs will still
>> be displayed in the API as a convenience to users but will not be accepted
>> for fields in POST/PUT requests.
>>
>> In order to support polymorphic fields, we'll also be adding a 'type'
>> field that will be returned for all objects that will contain the package
>> name and resource name (e.g. pulp_file.FileContent). This will allow these
>> objects to be posted to polymorphic fields like
>> add_content_units/remove_content_units (see below).
>>
>> Lastly, we also propose un-nesting the repository versions endpont and
>> making it a top-level resources. Filtering of repository versions
>> associated with a specific repo will be handled by repo filters, e.g.
>> /pulp/api/v3/repository_versions/?repository=3
>>
>>
>> RETURNING DATA
>>
>> Return for all objects:
>> - id
>> - _href
>> - type
>>
>> e.g. {'id': 4, 'type': 'pulp_file.FileContent', '_href': '
>> http://localhost:8000/pulp/api/v3/content/file/files/4/'}
>>
>> This includes polymorphic fields (e.g. created_resource on TaskStatus)
>>
>>
>> POSTING DATA
>>
>> Submitting data in general will use id only (no hrefs). For example:
>>
>> http http://localhost:8000/pulp/api/v3/remotes/file/3/sync repository=3
>>
>> Submitting polymorphic fields can be handled in the following way:
>>
>> add_content_units=[
>> {'id': 4, 'type': 'pulp_file.FileContent', '_href': '
>> http://localhost:8000/pulp/api/v3/content/file/files/4/'},
>> {'id': 4, 'type': 'pulp_python.PythonContent', '_href': '
>> http://localhost:8000/pulp/api/v3/content/python/p/4/'}
>> ]
>>
>> Note: the only fields that are inspected are id and type. the rest are
>> ignored. This simply allows users to pass back the data they receive from
>> the content endpoint.
>>
>>
>> We're holding off on proceeding until August 15th to allow time for
>> comment. Please respond with any concerns or feedback before then.
>>
>>
>> ___
>> 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] Plan to handle ids and hrefs
As per the other discussion thread, I assume the names will actually be
_id, _type, _href?
Errata have both "id" and "type" fields, so if we're going to attempt to
keep the Pulp metadata field names out of the way of Content field names,
we need to do it for all of them.
On Wed, Aug 8, 2018 at 12:02 PM, David Davis wrote:
> After recent meetings with stakeholders, we've arrived at a solution on
> how to handle ids and hrefs in the Pulp 3 API. The plan is to stop
> accepting hrefs for fields to instead rely solely on IDs. Hrefs will still
> be displayed in the API as a convenience to users but will not be accepted
> for fields in POST/PUT requests.
>
> In order to support polymorphic fields, we'll also be adding a 'type'
> field that will be returned for all objects that will contain the package
> name and resource name (e.g. pulp_file.FileContent). This will allow these
> objects to be posted to polymorphic fields like
> add_content_units/remove_content_units (see below).
>
> Lastly, we also propose un-nesting the repository versions endpont and
> making it a top-level resources. Filtering of repository versions
> associated with a specific repo will be handled by repo filters, e.g.
> /pulp/api/v3/repository_versions/?repository=3
>
>
> RETURNING DATA
>
> Return for all objects:
> - id
> - _href
> - type
>
> e.g. {'id': 4, 'type': 'pulp_file.FileContent', '_href': '
> http://localhost:8000/pulp/api/v3/content/file/files/4/'}
>
> This includes polymorphic fields (e.g. created_resource on TaskStatus)
>
>
> POSTING DATA
>
> Submitting data in general will use id only (no hrefs). For example:
>
> http http://localhost:8000/pulp/api/v3/remotes/file/3/sync repository=3
>
> Submitting polymorphic fields can be handled in the following way:
>
> add_content_units=[
> {'id': 4, 'type': 'pulp_file.FileContent', '_href': '
> http://localhost:8000/pulp/api/v3/content/file/files/4/'},
> {'id': 4, 'type': 'pulp_python.PythonContent', '_href': '
> http://localhost:8000/pulp/api/v3/content/python/p/4/'}
> ]
>
> Note: the only fields that are inspected are id and type. the rest are
> ignored. This simply allows users to pass back the data they receive from
> the content endpoint.
>
>
> We're holding off on proceeding until August 15th to allow time for
> comment. Please respond with any concerns or feedback before then.
>
>
> ___
> 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] Plan to handle ids and hrefs
After recent meetings with stakeholders, we've arrived at a solution on how
to handle ids and hrefs in the Pulp 3 API. The plan is to stop accepting
hrefs for fields to instead rely solely on IDs. Hrefs will still be
displayed in the API as a convenience to users but will not be accepted for
fields in POST/PUT requests.
In order to support polymorphic fields, we'll also be adding a 'type' field
that will be returned for all objects that will contain the package name
and resource name (e.g. pulp_file.FileContent). This will allow these
objects to be posted to polymorphic fields like
add_content_units/remove_content_units (see below).
Lastly, we also propose un-nesting the repository versions endpont and
making it a top-level resources. Filtering of repository versions
associated with a specific repo will be handled by repo filters, e.g.
/pulp/api/v3/repository_versions/?repository=3
RETURNING DATA
Return for all objects:
- id
- _href
- type
e.g. {'id': 4, 'type': 'pulp_file.FileContent', '_href': '
http://localhost:8000/pulp/api/v3/content/file/files/4/'}
This includes polymorphic fields (e.g. created_resource on TaskStatus)
POSTING DATA
Submitting data in general will use id only (no hrefs). For example:
http http://localhost:8000/pulp/api/v3/remotes/file/3/sync repository=3
Submitting polymorphic fields can be handled in the following way:
add_content_units=[
{'id': 4, 'type': 'pulp_file.FileContent', '_href': '
http://localhost:8000/pulp/api/v3/content/file/files/4/'},
{'id': 4, 'type': 'pulp_python.PythonContent', '_href': '
http://localhost:8000/pulp/api/v3/content/python/p/4/'}
]
Note: the only fields that are inspected are id and type. the rest are
ignored. This simply allows users to pass back the data they receive from
the content endpoint.
We're holding off on proceeding until August 15th to allow time for
comment. Please respond with any concerns or feedback before then.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
Re: [Pulp-dev] 'id' versus 'pulp_id' on Content
On Tue, Aug 7, 2018 at 6:47 PM, Jeff Ortel wrote: > After long consideration, I have had a change of heart about this. I > think. In short, Pulp's data model has unique requirements that make it > acceptable to deviate from common convention regarding ID as the PK. > Mainly that the schema is extensible by plugin writers. Given the plugin > architecture, I think it's reasonable to think of "core" fields like: ID, > CREATED and LAST_MODIFIED as metadata. Although, the ID is harder to fit > in this semantic, I think it's reasonable to do for consistency and to > support the user query use-case re: content having an natural ID > attribute. Taking this further, the *href* attributes *could* be though > of in the same category. > > With this in mind, I'm thinking that the leading underscore (_) could be > used broadly to denote *generated* *or metadata* fields and the following > would be reasonable: > > _id > _created > _last_updated > > _href > _added_href > _removed_href > _content_href > > I highly value consistency so this applies to the entire schema. > I'd even go as far as making a distinct core attribute of a plug-in provided model: rpm.core.id, rpm.core.href, namespacing the model and promoting composition. This would have the benefit of being able to easily distinguish between platform and plug-in specific data especially if plug-in specific data is expected to be the main user interaction site i.e user_importance(rpm.id) > user_importance(rpm.core.id). -- milan > This will introduce a few fairly odd things into the schema that I > *suppose* we can live with. > > - Two fields on *some* tables named (ID , _ID). To mitigate confusion, > we should serialize the *pk* and not* _id*. This will also be consistent > with *pk* parameters passed in. > - I expect django will generate foreign key fields with double > understores. Eg: content__id > > I'm still -1 for using a *pulp_* prefix. > > Thoughts? > > > On 06/18/2018 01:15 PM, Daniel Alley wrote: > > I'm -1 on going the underscore idea, partly because of the aforementioned > confusion issue, but also partly because but I've noticed that in our API, > the "underscore" basically has a semantic meeting of "href, [which is] > generated on the fly, not stored in the db". > > Specifically: > >- '_href' >- '_added_href' >- '_removed_href' >- '_content_href' > > So I think if we use a prefix, we should avoid using one that already has > a semantic meaning (I don't know whether we actually planned for that to be > the case, but I think it's a useful pattern / distinction and I don't think > we should mess with it). > > > > ___ > 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
