<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_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><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">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_-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_-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_-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>