On 10/23/2017 11:30 AM, Dennis Kliban wrote: > That is exactly what I had in mind. Though the field can be NULL if the task > has been removed from the > database already. This way a serialized version of a Publication would > provide a reference to a task that can > be tracked to see if the publication was successfully created. If a failure > occurs, the user can choose to > delete the publication. Why do you think it's not a good idea to add this > association?
Mainly for 2 reasons: 1. Knowing which task created a publication is only useful for a short amount of time. For example, making a subsequent API call. However the related task is pretty much meaningless (to a user) when listing publications and trying to decide which to use to update a distribution or delete. 2. We don't do this for any other resource created by a task. > > > I still like the idea of adding Publication.name as a natural key that > can be specified by the user. It can > default to the task ID when not specified. This gives users something > meaningful to use when selecting a > publication for association to a Distribution or when deleting. > > > I also think it's valuable to let users name their publications. However, we > should avoid forcing users to > form URLs to resources on their own. Jeremy put it well in his response. I was not aware that was suggested.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
