<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 23, 2017 at 12:30 PM, Dennis Kliban <span dir="ltr"><<a href="mailto:dkliban@redhat.com" target="_blank">dkliban@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Oct 23, 2017 at 10:56 AM, Jeff Ortel <span dir="ltr"><<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is interesting.<br>
<br>
Some thoughts:<br>
<br>
If adopted, I propose the publication task create the publication and pass to the publisher which would<br>
require a change in the plugin API - Publisher.publish(publication)<wbr>.  If the publisher fails, I think the<br>
publication should be deleted.<br></blockquote><div><br></div></span><div>The ViewSet would create the publication, dispatch a publish task with the publication id as an argument, update the publication with the task id, return a serialized Publication to the API user. The user is responsible for deleting any publication that is not created successfully. <br></div></div></div></div></blockquote><div><br></div><div>For me, your wording illustrates the problem well. Why should a user have to delete a resource that was never created?</div><div><br></div><div>This sounds like we'd be introducing a partially-created state for publications. There would be some kind of placeholder representation that could be referenced as a location where a real publication *might or might not* eventually appear. And this representation would live side-by-side in a "publications/" endpoint with representations of actual publications? How would a user know which are which? It seems like this just shifts the async problem onto the publication model.</div><div><br></div><div>I go back to this: When creation of a resource is requested, the response should either be 201 if the resource was created, or 202 if creation is deferred. We should not attempt partial creation.</div><div><br></div><div>It's easy to lose sight of this, so maybe it's worth also observing that a resource is not just a DB record or some JSON. The existence of a resource representation requires that the resource itself exists in every way that is necessary for it to make sense. We should be careful not to misrepresent the existence of a publication. </div><div> </div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Michael</span> <span style="margin:0px!important;padding:0px!important">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><span style="margin:0px!important;padding:0px!important">Principal Software Engineer</span><span style="margin:0px!important;padding:0px!important">, <span style="margin:0px!important;padding:0px!important">RHCE</span></span> </span><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px"></span><br style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px!important;padding:0px!important">Red Hat</p></div></div>
</div></div>