[Pulp-dev] Master-detail inheritance in Pulp 3
daviddavis at redhat.com
Tue Apr 23 15:01:43 UTC 2019
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".
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 that was
> recently encountered in Pulp 3 that affects how the Pulp 3 plugin API
> # 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 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 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. 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.
>  https://pulp.plan.io/issues/4681
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev