[Pulp-dev] 'id' versus 'pulp_id' on Content
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
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:
> 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.
> 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.
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev