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

Brian Bouterse bbouters at redhat.com
Thu Aug 16 18:58:47 UTC 2018


I'm currently reworking the Content unit to not use MasterDetail (
https://pulp.plan.io/issues/3812). I will make the changes I think I heard
on this thread as part of that work. Specifically I plan to have the top
level Pulp model that all objects inherit from define:  _id, _created, and
_updated. Let me know if I should not do this.

re creating mutable vs immutable model types: I don't think it's worth the
complexity.

On Mon, Aug 13, 2018 at 10:38 AM, Jeff Ortel <jortel at redhat.com> wrote:

>
>
> On 08/07/2018 11:47 AM, 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
>
>
> I'm convinced that all tables should have _created.  Knowing when
> something is created helps fulfill many common use cases and is essential
> for troubleshooting.  I am open to including _last_updated only on mutable
> entities .  Depending on the number (ratio) of mutable/immutable entities,
> we could support this with either an additional Model class eg:
> MutableModel or just add _last_updated on concrete models.  Either way, the
> column (attribute) needs to be named consistently.
>
>
> _href
> _added_href
> _removed_href
> _content_href
>
> I highly value consistency so this applies to the entire schema.
>
> 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?
>
>
>
> _______________________________________________
> 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/20180816/19d412c0/attachment.htm>


More information about the Pulp-dev mailing list