[Pulp-dev] [pulp 3] cast() method for casting from a Master to Detail model instance

Brian Bouterse bbouters at redhat.com
Tue Jun 6 14:33:56 UTC 2017

We could do that, but we would have to do it in many places. Wouldn't it be
better to centralize the Exception raising in one place?

I'm looking for a case where cast() is called, yet it is correct for cast()
to transform the type sometimes but not others. If that situation exists
then what I'm proposing isn't right. Does this situation exist?

On Mon, Jun 5, 2017 at 2:08 PM, Austin Macdonald <amacdona at redhat.com>

>> 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?
> Rather than adding an argument to cast we could just catch the
> `AttributeError`.
> From the publish example [0]:
> try:
>     publisher.publish() # publish is defined on the detail model, never
> the master model.
> except AttributeError as e:
>     raise SomePulpCodedException
>> [0]: https://github.com/pulp/pulp/commit/bf7433236c5cf5203808341c
>> 74715ad257d69718#diff-5e2d175476716cc65d5d2d61b7eb5efdR35
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170606/9f473ef5/attachment.htm>

More information about the Pulp-dev mailing list