<div dir="ltr">Thanks for that explanation. That makes sense. I would describe this as saying there is a many-to-many relationship between Content and Artifact, and the ContentArtifact is the "glue" or "through" table.<div><br></div><div>And again to just understand why... are we deliberately trying to prioritize a use case where one artifact is shared by multiple Content units? Can someone talk about the pros and cons of that within the context of this proposal? I expect it could save a small portion of disk space, but maybe not very much. Pulp does a pretty good job of de-duplicating at the Content level. Changing to a m2m relationship would definitely add more complexity though, and that's the aspect I'm interested in comparing to what value we are seeking.<br><div><br></div><div>Separate from that relationship question, we have a use case that the direct-to Artifact workflow does not cover. There are multiple unit types where a user wants to upload a single file that represents multiple content units, and let pulp create one or more content units based on that file. For example, a docker manifest and its blobs all get saved to disk together (by a separate tool) and then uploaded as a tarball that Pulp can receive and process together. We could ask the upload client to open up the tarball and upload files individually I suppose. That puts more burden on the client though.</div></div><div><br></div><div>Another example: a user can upload a comps.xml file, and pulp will parse it to create as many units as it finds in the XML. Pulp does not keep that comps.xml file, so in the proposed workflow, it would need to delete the Artifact at the end. It seems unexpected to utilize an Artifact as temporary storage in this way.</div><div><br></div><div>I suspect we'll find more use cases like this. Thoughts? Is the FileUpload really worth eliminating? What I like about the current upload workflow, and the FileUpload workflow, is that it allows the plugin to receive any file or set of files that make sense within its domain, and then use that set of files to create units however it sees fit. It is difficult to get more prescriptive than that at the platform/core level.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 8:47 AM, 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 Thu, Jun 29, 2017 at 7:40 AM, Michael Hrivnak <span dir="ltr"><<a href="mailto:mhrivnak@redhat.com" target="_blank">mhrivnak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="m_8953507853256652190gmail-"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 7:22 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><div><br></div></span><div>The many to many relationship is between Artifact and ContentArtifact. This allows a content unit to have multiple Artifacts associated with it.</div></blockquote></div><br></span>Could you elaborate on this? A content unit can have multiple artifacts just by artifact having a foreign key to a content unit. That's the one-to-many relationship we have on the model now in 3.0-dev.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, what is a ContentArtifact?<span class="m_8953507853256652190gmail-"><br><br clear="all"></span></div></div></blockquote><div><br></div></span><div>Here are some definitions for the new proposal:<br></div><ul><li>Artifact - a file stored in pulp</li><li>Content - a named collection of 0 or more Artifacts that can be associated with a repository as a single unit</li><li>ContentArtifact - a relationship between an Artifact and Content. There is 0 or more ContentArtifacts for each Content.</li><li>Repository - A named collection of content.</li><li>RepositoryContent - a relationship between Content and Repository. </li></ul><div><br>In the proposal we have in the MVP we have the following:<br><ul><li>FileUpload - Uploaded file that is used to create Artifacts and is then removed (definition for this is not present in the glossary of MVP)<br></li><li>Artifact - A file associated with one content (unit). Artifacts are not shared between content (units). Create a content unit using an uploaded file ID as the source for its metadata. Create Artifacts associated with the content unit using an uploaded file ID for each; commit as a single transaction.</li><li>Content (unit) - A single piece of content manged by Pulp. Each file associated with a content (unit) is called an Artifact. Each content (unit) may have zero or many Artifacts.</li><li>Repository - A named collection of content.</li><li>RepositoryContent - a relationship between Content and Repository (also not in the glossary of the MVP)<br></li></ul><p>In the MVP in order to add a unit to a repository, a user would:</p><ol><li>Create a FileUpload by uploading a file<br></li><li>Create an Artifact and a Content with one API call</li><li>Associate a Content with a Repository</li><li>Delete the FileUpload (or some cleanup job would do that for the user)</li></ol><p>The newly proposed workflow:</p><ol><li>Create an Artifact by uploading a file</li><li>Create a Content by specifying which Artifact(s) belongs to the Content and their relative paths inside the unit. This creates ContentArtifacts for each relationship.</li><li>Associate a Content with a repository.</li></ol><p>In the MVP workflow, once an FileUpload is deleted, it's hard to create another Content from that file. I am sure we can come up with a way to do it, but it won't be as straight forward as the above workflow.</p><p></p></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="m_8953507853256652190gmail-"><div><br></div>-- <br><div class="m_8953507853256652190gmail-m_7153167500244933577gmail_signature"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Michael</span> <span style="margin:0px;padding:0px">Hrivnak</span></p><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"></p><span style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px"><span style="margin:0px;padding:0px">Principal Software Engineer</span><span style="margin:0px;padding:0px">, <span style="margin:0px;padding:0px">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;padding:0px"><p style="color:rgb(0,0,0);font-family:overpass-mono,monospace;font-size:10px;margin:0px;padding:0px">Red Hat</p></div></div>
</span></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></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>