[Pulp-dev] 'id' versus 'pulp_id' on Content
Jeff Ortel
jortel at redhat.com
Tue Aug 7 16:47:40 UTC 2018
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.
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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180807/df6b5107/attachment.htm>
More information about the Pulp-dev
mailing list