<div dir="ltr"><div><div>+1 to a guard feature that warns when there are content types in the db that are not present with entry points. I filed that here:  <a href="https://pulp.plan.io/issues/2779">https://pulp.plan.io/issues/2779</a><br><br></div>I think there is still an improvement to be made with cast() when it fails to cast. The cast method itself can't know if you're dealing with the master or most detailed object, but the code author calling cast() always knows and if they don't need it cast() they shouldn't call cast(). For example the publish code here [0]. The publish code calls cast() because it needs the type to be the detail version of models.Publisher. Anytime the plugin writer (or core) looks up a master instance and calls cast() and it returns the exact same object that was requested to be cast() that should cause an error instead of failing silently. What do you all think about this?<br><br></div><div>What I'm thinking of is something like this hastily-written diff which is similar to what @dkliban mentioned in his email.<br></div><div><br>diff --git a/platform/pulp/app/models/base.py b/platform/pulp/app/models/base.py<br>index ead4301..c9248fc 100644<br>--- a/platform/pulp/app/models/base.py<br>+++ b/platform/pulp/app/models/base.py<br>@@ -90,7 +90,7 @@ class MasterModel(Model):<br>             self.type = self.TYPE<br>         return super(MasterModel, self).save(*args, **kwargs)<br> <br>-    def cast(self):<br>+    def cast(self, depth=0):<br>         """Return a "Detail" model instance of this master-detail pair.<br> <br>         If this model is already an instance of its detail type, it will return itself.<br>@@ -104,12 +104,14 @@ class MasterModel(Model):<br>                 # related detail table. Cast and resturn this value, recursively following<br>                 # master/detail relationships down to the last table (the most detailed).<br>                 try:<br>-                    return getattr(self, <a href="http://rel.name">rel.name</a>).cast()<br>+                    return getattr(self, <a href="http://rel.name">rel.name</a>).cast(depth + 1)<br>                 except AttributeError:<br>                     continue<br>         else:<br>             # The for loop exited normally, there are no more detailed models than this<br>             # one in this instance's master/detail ancestry, so return here.<br>+            if depth == 0:<br>+                raise PulpCodedException('Could not cast to detail()')<br>             return self<br> <br>     @property<br><br>[0]: <a href="https://github.com/pulp/pulp/commit/bf7433236c5cf5203808341c74715ad257d69718#diff-5e2d175476716cc65d5d2d61b7eb5efdR35">https://github.com/pulp/pulp/commit/bf7433236c5cf5203808341c74715ad257d69718#diff-5e2d175476716cc65d5d2d61b7eb5efdR35</a><br><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 26, 2017 at 5:15 PM, Sean Myers <span dir="ltr"><<a href="mailto:sean.myers@redhat.com" target="_blank">sean.myers@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/26/2017 11:41 AM, Dennis Kliban wrote:<br>
> Looking at the cast() method[0] it looks like it's possible to call cast()<br>
> on a detail model. I would like to figure out when we expect to call cast()<br>
> on a detail model. Without fully knowing the motivation for this<br>
> implementation, I am inclined to raise an exception when the code reaches<br>
> line 113. The exception would inform the developer that calling cast() is<br>
> only appropriate on a master model.<br>
<br>
</span>You don't always know if you're dealing with a master model instance<br>
or its related cast detail model instance. This method makes calling<br>
cast on a detail instance a no-op, so it costs when you need to pay<br>
the price, and is free when you don't. It also has the effect that<br>
"instance is instance.cast()" when casting detail instances. As<br>
Michael pointed out, raising an exception here would be an expection<br>
antipattern (raising exceptions in non-exceptional cases).<br>
<span class=""><br>
On 05/26/2017 04:27 PM, Dennis Kliban wrote:<br>
> The problem occurs when a worker receives a task to perform a publish, but<br>
> it doesn't have the plugin installed.<br>
<br>
</span>The problem is that the plugin is not installed on the worker, so fix<br>
*that* problem. Install the plugin on the worker. If anything should<br>
raise an exception, it should be a warning on worker start that<br>
unknown content types exist in the db, including what the master type<br>
is and what the unknown content types are.<br>
<br>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>