[Pulp-dev] 'id' versus 'pulp_id' on Content

[Milan Kovacik]

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:
>
> _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 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/20180808/7ff136f7/attachment.htm>