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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
