Wow we both responded at the same time! Spawned tasks are a good example of something any task could need, so it is its own attribute as 'spawned_tasks' here [3]. I like it being its own attribute versus a field in a result because it's more structured and it's filterable then easily too.
[3]: https://github.com/pulp/pulp/blob/b86677f069c03643380d98bc51cd1291fdfa3289/platform/pulp/app/models/task.py#L157 On Mon, May 8, 2017 at 4:48 PM, Michael Hrivnak <[email protected]> wrote: > > On Mon, Apr 24, 2017 at 3:48 PM, Jeff Ortel <[email protected]> wrote: > >> The >> "result" report /could/ provide an indicator of success and a >> summary/detail of work completed. These two >> things seem completely different. I'm not advocating for a "result", >> just pointing out the differences. >> > > Exactly. If tasks had a "result" field, it should contain references to > whatever the task produced. If we start tracking things like publications > and repo versions, then it could make sense for the task to contain a > result field with an appropriate reference to the object(s) it created. > > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
