[Pulp-dev] Master-detail inheritance in Pulp 3

Austin Macdonald amacdona at redhat.com
Tue Apr 23 15:13:07 UTC 2019

If the plugin writers have to be involved, then they will have to
understand this problem which isn't much improved over situation right
now-- the plugins will still be responsible for making sure their names
don't collide with other plugins. If it is reasonable to do, the plugin
writer experience will be simpler, and impossible to collide if we can
automagically namespace detail models by the app label.

On Tue, Apr 23, 2019 at 11:02 AM David Davis <daviddavis at redhat.com> wrote:

> 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".
> David
> On Tue, Apr 23, 2019 at 10:29 AM David Davis <daviddavis at redhat.com>
> wrote:
>> 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.
>> # Problem
>> 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.
>> 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'.")
>> 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.
>> # Potential Solutions
>> ## Class Naming
>> 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.
>> ## Defining OneToOneField
>> 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.
>> ## Abstract Class
>> 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.
>> 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.
>> [0] https://pulp.plan.io/issues/4681
>> [1]
>> https://docs.djangoproject.com/en/2.2/topics/db/models/#multi-table-inheritance
>> [2]
>> https://docs.djangoproject.com/en/2.2/topics/db/models/#specifying-the-parent-link-field
>> [3]
>> https://docs.djangoproject.com/en/2.2/topics/db/models/#abstract-base-classes
>> David
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20190423/69ed4353/attachment.htm>

More information about the Pulp-dev mailing list