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 <davidda...@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@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev
