<div dir="ltr"><div>That is a great reason to not use the underscore prefix also for that. We've never formally called this out (that I know of) so that is useful.</div><div><br></div><div>A good prefix is tough to come up with. Part of the issue is that changing MasterModel affects all models so a prefix like 'pulp_id' would affect all models even though the collision concern is only for subclasses of Content. A name like pulp_id would look very strange on a Distributor, Repository, Remote, etc.<br></div><div><br></div><div>In terms of Content though, is anyone else concerned that 'created_at' and 'updated_at' will be very ambiguous to end users? Does it mean when the rpm was made or when it was added to Pulp? I think this question will come up a lot. I believe all this stems from us loading up Content with fields that a) plugin writer's have to deal with and b) users have to figure out.<br></div><div><br></div><div>There is another option to consider. What if 'Content' didn't inherit the fields from MasterModel and instead just defined pulp_id as the primary key only for Cotnent? Content would still have the functionality of MasterModel, just not the inherited fields. That would resolve the issues without needing a convention or the need to 'separate' the fields. We (I think) have to keep 'artifacts' and/or call them 'pulp_artifacts' because Content units need a foreign key so we have to name it something. All code could refer to the pk as 'pk', which is why Django has this feature to handle differing pk field names. End users would clearly see the pulp_artifacts and pulp_id on serialized Content units. Other pulp objects would serialize with 'id', 'created_at', etc like we have today.</div><div><br></div><div>What do you all think about ^?<br></div><div><br></div><div>As an aside, calling the field 'pk' is not an option either. A little test I ran throws this django error on the model definition: <a href="http://hello.my_model.pk">hello.my_model.pk</a>: (fields.E003) 'pk' is a reserved word that cannot be used as a field name.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 18, 2018 at 2:15 PM, Daniel Alley <span dir="ltr"><<a href="mailto:dalley@redhat.com" target="_blank">dalley@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 dir="ltr"><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><div></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).<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 18, 2018 at 2:01 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@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 dir="ltr"><div>Having a user focus made me realize that it would be useful if a user could easily tell which attributes were common to all content units versus just that one content unit. When scripting for instance that is really useful to know. We could document the 5 attributes that platform provides, but when there are 20+ attributes on a subclassed content unit the underscores would provide an easy, consistent answer to this question. This is an additional reason separate from the the issue that our content attribute names are colliding (id at least for now). The underscore prefix would make collisions highly unlikely also. This problem is only scoped to the Content unit since that is the place where we expect a large number of subclassed attributes.<br></div><div><br></div><div>For this reason I believe using the _ as the prefix will provide 2 benefits. I wrote them here on this ticket:  <a href="https://pulp.plan.io/issues/3704" target="_blank">https://pulp.plan.io/issues/37<wbr>04</a></div><div><br></div><div>I am still +1 on adopting those changes for those reasons. More feedback is welcome given the additional problem statements and discussion.<br></div></div><div class="m_-4697342003201510959HOEnZb"><div class="m_-4697342003201510959h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 18, 2018 at 8:43 AM, Ina Panova <span dir="ltr"><<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@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 dir="ltr">uuid sounds like good compromise.<br></div><div class="gmail_extra"><br clear="all"><div><div class="m_-4697342003201510959m_-7360613270181842854m_4152275193296911872gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div><div><div class="m_-4697342003201510959m_-7360613270181842854h5">
<br><div class="gmail_quote">On Thu, Jun 14, 2018 at 9:38 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"><span><br>
<br>
On 06/14/2018 12:19 PM, Jeff Ortel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 06/14/2018 10:37 AM, Daniel Alley wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I will make one more suggestion.  What about naming "id" -> "uuid"?  This carries the clear connotation that it is a unique identifier so it is less likely to be confusing a la "id and _id", and is still less likely to have a namespace conflict.<br>
</blockquote>
<br>
Appreciate the suggestion but this would only be marginally less confusing.<br>
</blockquote>
<br></span>
Reconsidering this suggestion for the reasons you outlined.<div class="m_-4697342003201510959m_-7360613270181842854m_4152275193296911872HOEnZb"><div class="m_-4697342003201510959m_-7360613270181842854m_4152275193296911872h5"><br>
<br>
______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>