[Pulp-dev] 'id' versus 'pulp_id' on Content
mkovacik at redhat.com
Wed Aug 8 07:39:56 UTC 2018
On Tue, Aug 7, 2018 at 6:47 PM, Jeff Ortel <jortel at redhat.com> 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:
> 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
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) >
> 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.
> 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".
> - '_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 at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev