<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 08/07/2018 11:47 AM, Jeff Ortel
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:653b1ba3-e82e-c242-0cff-d7b94725cdfe@redhat.com"> 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 <i>href</i> attributes <i>could</i> be
though of in the same category.<br>
<br>
With this in mind, I'm thinking that the leading underscore (_)
could be used broadly to denote <i>generated</i> <i>or metadata</i>
fields and the following would be reasonable:<br>
<br>
_id<br>
_created<br>
_last_updated<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:653b1ba3-e82e-c242-0cff-d7b94725cdfe@redhat.com"> <br>
_href<br>
_added_href<br>
_removed_href<br>
_content_href<br>
<br>
I highly value consistency so this applies to the entire schema.<br>
<br>
This will introduce a few fairly odd things into the schema that I
<i>suppose</i> we can live with.<br>
<br>
- Two fields on <i>some</i> tables named (ID , _ID). To
mitigate confusion, we should serialize the <b>pk</b> and not<b>
_id</b>. This will also be consistent with <b>pk</b>
parameters passed in.<br>
- I expect django will generate foreign key fields with double
understores. Eg: content__id<br>
<br>
I'm still -1 for using a <i>pulp_</i> prefix.<br>
<br>
Thoughts?</blockquote>
<br>
</body>
</html>