<div dir="ltr">I think my main concern with the solution to remove model inheritance is that we either only apply it to the Content model and run the risk of having conflicts in other Master/Detail models (unlikely but possible). Or we apply it to all M/D models which is a huge undertaking (unless we can create some general solution?).<div><div><br></div><div><div><div dir="ltr" class="m_-6748620541961637410m_3614279910614214046m_-3001825632113136171gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 10:09 AM Dana Walker <<a href="mailto:dawalker@redhat.com" target="_blank">dawalker@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I like your solution using default_related_name [0] manually, as Brian noted [1], it's more explicit and therefore more pythonic.</div><div><br></div><div>That in mind, Daniel's alternative, not using model inheritance for the Content models [2], while less simple a change initially, potentially had significant performance gains and is also more explicit and pythonic.</div><div><br></div><div>Should we still pursue this more complex fix for the improvements to bulk_create since we'd rather have breaking changes early in development than need to address them later?</div><div><br></div><div>Or am I putting the cart before the horse by seeking optimization too early?<br></div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/4681#note-19" target="_blank">https://pulp.plan.io/issues/4681#note-19</a></div><div>[1] <a href="https://pulp.plan.io/issues/4681#note-20" target="_blank">https://pulp.plan.io/issues/4681#note-20</a></div><div>[2] <a href="https://pulp.plan.io/issues/4681#note-11" target="_blank">https://pulp.plan.io/issues/4681#note-11</a></div><div><br></div><div><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>
        <p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:capitalize;font-family:RedHatText,sans-serif">
          <span>Dana</span> <span>Walker</span><span style="color:rgb(170,170,170);margin:0px"></span>
        </p>
        <p style="font-weight:normal;font-size:12px;margin:0px 0px 4px;text-transform:capitalize;font-family:RedHatText,sans-serif">She / Her / Hers</p>
        <p style="font-weight:normal;font-size:12px;margin:0px;text-transform:capitalize;font-family:RedHatText,sans-serif">
          <span>Software Engineer, Pulp Project</span>
        </p>
        <p style="font-weight:normal;margin:0px 0px 4px;font-size:12px;font-family:RedHatText,sans-serif">
          <a style="color:rgb(0,136,206);font-size:12px;margin:0px;text-decoration:none;font-family:RedHatText,sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span></span></a>
        </p>
    <div style="margin-bottom:4px">
      
      
    </div>
    <p style="font-weight:normal;margin:0px;font-size:12px;font-family:RedHatText,sans-serif">
      <span style="margin:0px;padding:0px"><a style="color:rgb(0,0,0);font-size:12px;margin:0px;text-decoration:none;font-family:RedHatText,sans-serif" href="mailto:dawalker@redhat.com" target="_blank">dawalker@redhat.com</a>   </span>
      
      
    </p>
    
    

    <div style="margin-top:12px">
      <table border="0">
        <tbody><tr>
          <td width="100px"><a href="https://www.redhat.com" target="_blank"> <img src="https://marketing-outfit-prod-images.s3-us-west-2.amazonaws.com/f5445ae0c9ddafd5b2f1836854d7416a/Logo-RedHat-Email.png" width="90" height="auto"></a> </td>
          
        </tr>
      </tbody></table>
    </div>

  </div><table border="0"><tbody><tr><td width="100px"><br></td>
</tr></tbody></table>

</div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 24, 2019 at 8:24 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I want to bump this thread again. We've only had one person weigh in and this is a major change that'll affect all Pulp 3 plugins that we need to address soon. Please respond here or on the issue with feedback.<br clear="all"><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail-m_469544745372654473gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 21, 2019 at 10:49 AM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for the investigation and demo patch. I posted a +1 for the manual option with reasoning here: <a href="https://pulp.plan.io/issues/4681#note-20" target="_blank">https://pulp.plan.io/issues/4681#note-20</a></div><div><br></div><div>Other ideas and perspectives are welcome. I hope we can resolve this issue soon as we approach RC4.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 17, 2019 at 12:55 PM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I did some investigation and posted my findings[0]. Basically, it would be possible to solve this problem by defining default_related_name either manually or automatically on detail models. I don't know if we want to go this route so feedback is appreciated.<div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/4681#note-19" target="_blank">https://pulp.plan.io/issues/4681#note-19</a><br clear="all"><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail-m_469544745372654473gmail-m_-1028399561377562510gmail-m_-6812729864926286682gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 2:16 PM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">It seems like most people are in favor of setting the OneToOneField or perhaps the default_related_name on the detail model. I think there’s also some interest in seeing how we can do this automatically for plugins. I’ve added this feedback to the issue:</div><div dir="ltr"><br></div><div dir="ltr"><a href="https://pulp.plan.io/issues/4681#note-8" target="_blank">https://pulp.plan.io/issues/4681#note-8</a><br clear="all"><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail-m_469544745372654473gmail-m_-1028399561377562510gmail-m_-6812729864926286682gmail-m_-4587856402411284498gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2019 at 6:22 AM Ina Panova <<a href="mailto:ipanova@redhat.com" target="_blank">ipanova@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I would avoid making changes in class naming. So +1 for the OneToOneField definition.<br clear="all"><div><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail-m_469544745372654473gmail-m_-1028399561377562510gmail-m_-6812729864926286682gmail-m_-4587856402411284498gmail-m_-8504612151428324700gmail_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><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 6:45 PM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">The default_related_name setting is something that django provides. Subclasses can also explicitly define their OneToOneField parent link as well:<br clear="all"><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail-m_469544745372654473gmail-m_-1028399561377562510gmail-m_-6812729864926286682gmail-m_-4587856402411284498gmail-m_-8504612151428324700gmail-m_-1907940321948692473m_-6878639782336224048m_4396941712807809596gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>content_ptr = models.OneToOneField(Content, on_delete=models.CASCADE, parent_link=True, related_name='rpm_package')<br></div><div><br></div><div>I am not sure what you mean by 'robust' but if a plugin subclass doesn't do either of these, it may not work with other plugins. </div><div><br></div><div>I think the question now would be whether we should just document this or try to do it automagically for plugins?</div><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 12:31 PM Brian Bouterse <<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 11:02 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">I think I found another solution that might work best: defining 'default_related_name' on subclassed master-detail models. So Package in pulp_rpm would define its default_related_name as "rpm_package".<br clear="all"></div></div></div></blockquote><div>Would we be making 'default_related_name' or is that something Django is
 providing? If it's something Pulp would be providing perhaps defining 
the explicit one-to-one field is better. Any plugin that takes the step 
of defining the one-to-one field will insulate themselves from other 
plugins. If plugins don't take that step they will still work, just not 
as robustly. Am I thinking about this correctly?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail-m_469544745372654473gmail-m_-1028399561377562510gmail-m_-6812729864926286682gmail-m_-4587856402411284498gmail-m_-8504612151428324700gmail-m_-1907940321948692473gmail-m_-6878639782336224048gmail-m_4396941712807809596gmail-m_-5442075329392407997gmail-m_-2962124617103980890gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 23, 2019 at 10:29 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I wanted to email the pulp-dev list about a major problem[0] that was recently encountered in Pulp 3 that affects how the Pulp 3 plugin API functions.<div><br></div><div># Problem</div><div><br></div><div>In the plugin API we rely on inheritance to allow plugin writers to import functionality into their plugin. This includes models such as Remote and Content that are inherited by plugins. We rely on django's multi-table inheritance[1] for these models. </div><div><br></div><div>Behind the scenes, django defines a OneToOneField and a reverse accessor. This field is not namespace so if two subclasses have the same name, you get an error ("Reverse accessor for 'Package.content_ptr' clashes with reverse accessor for 'Package.content_ptr'.")</div><div><br></div><div>To give an actual example, both the Debian and RPM plugins implement a Package class. This causes an error to be raised when a user installs both plugins. Django tries to define a 'package' reverse accessor for both subclasses and blows up.</div><div><br></div><div># Potential Solutions</div><div><br></div><div>## Class Naming</div><div><br></div><div>The first solution I can think of which is probably also the simplest and most straightforward would be to require plugin writers to namespace their master/detail subclass names. So Package would be RpmPackage. This places the onus on plugin writers to name their master/detail classes correctly.</div><div><br></div><div>## Defining OneToOneField</div><div><br></div><div>The other solution would be to either manually define the OneToOneField on the subclasses[2] and specify a namespaced field name. There may be a way to do this dynamically (ie magically) in the parent somehow as well.</div><div><br></div><div>## Abstract Class</div><div><br></div><div>Lastly, we could redefine master models as abstract classes[3]. I can think of at least one or two places (e.g. content field on RepositoryVersionContent, publisher field on Publication) that would have to switch their relationships to generic relationships in order to accommodate this change.</div><div><br></div><div>There might be other solutions I am not thinking of so feel free to propose something. Also, quick feedback would be greatly appreciated as this is going to be a major change in our plugin API.</div><div><br></div><div>[0] <a href="https://pulp.plan.io/issues/4681" target="_blank">https://pulp.plan.io/issues/4681</a></div><div>[1] <a href="https://docs.djangoproject.com/en/2.2/topics/db/models/#multi-table-inheritance" target="_blank">https://docs.djangoproject.com/en/2.2/topics/db/models/#multi-table-inheritance</a><br clear="all"><div><div dir="ltr" class="gmail-m_-6748620541961637410gmail-m_3614279910614214046gmail-m_-3001825632113136171gmail-m_5227948291483948432gmail-m_469544745372654473gmail-m_-1028399561377562510gmail-m_-6812729864926286682gmail-m_-4587856402411284498gmail-m_-8504612151428324700gmail-m_-1907940321948692473gmail-m_-6878639782336224048gmail-m_4396941712807809596gmail-m_-5442075329392407997gmail-m_-2962124617103980890gmail-m_250689715570937350gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>[2] <a href="https://docs.djangoproject.com/en/2.2/topics/db/models/#specifying-the-parent-link-field" target="_blank">https://docs.djangoproject.com/en/2.2/topics/db/models/#specifying-the-parent-link-field</a></div><div>[3] <a href="https://docs.djangoproject.com/en/2.2/topics/db/models/#abstract-base-classes" target="_blank">https://docs.djangoproject.com/en/2.2/topics/db/models/#abstract-base-classes</a></div><div><br></div><div>David<br></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div>
_______________________________________________<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/listinfo/pulp-dev</a><br>
</blockquote></div></div>
</blockquote></div>
_______________________________________________<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/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<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/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div>