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

[Tatiana Tereshchenko]

I'm leaning towards option 2 "defining one-to-one field". Are there any
downsides of that approach apart from one more field specified by plugin
writers?
It will keep class names and autogenerated endpoints nice and less
redundant, and fair for all the plugins.

On Tue, Apr 23, 2019 at 4:31 PM 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/9f736598/attachment.htm>