<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>I'm on board with this, I think your revised description of what '_' could symbolize makes a lot of sense.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 7, 2018 at 12:47 PM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    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>
    <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?<span class=""><br>
    <br>
    <br>
    <div class="m_4164699859443627971moz-cite-prefix">On 06/18/2018 01:15 PM, Daniel Alley
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div>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".</div>
      <div><br>
      </div>
      <div>Specifically:</div>
      <ul>
        <li> '_href'</li>
        <li> '_added_href'</li>
        <li> '_removed_href'</li>
        <li> '_content_href'</li>
      </ul>
      <div>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).</div>
    </blockquote>
    <br>
  </span></div>

<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>