<div dir="ltr">tl;dr - do we want to store a direct association between a repo version and a content unit or just the changes between each version?<br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>There has been discussion about how to implement the association between a repo version and a content unit and two implementations have been proposed. The first would store a direct relation between a repo version and a content unit. The other proposal is currently captured in @mhrivnak’s PR[0] and involves storing changes—the addition/removal of a content unit. I see some benefits to both approaches so let me outline them.</div><div><br></div><div>For the first proposal (the direct association), I find this to be more intuitive and simplistic. To get a list of content for a repo version, you simply would need to filter by the repo version id. Also, deleting a version is trivial: we would just need to remove the version from the database. On the other hand, deleting a repo version when you are storing changes means having to squash the changes.</div><div><br></div><div>The second proposal of storing the differences in each version (compared to the previous version) has the advantage of storing less data in the database. For example, if you added a single content unit to a version, you’d only need to store one record for the new version no matter how many content units a repository has. Filtering is a little harder (you need to select the repo contents with version_added gte version and version_removed is NULL) but not overly complicated. It’s a bit of a more efficient solution but slightly harder to grok maybe. </div><div><br></div><div>If we want to support the use case of allowing users to create a new version from a base version (as opposed to just the latest version) then the second proposal is a bit tricky I think. Either we have to store the changes in the context of the base case (which makes the filtering algorithm I described harder) or we have to re-compute the changes between the new version and the latest version when we store them in the db.</div><div><br></div><div>It sounded like during our meetings most people were in favor of the first proposal. Interested to get people’s thoughts especially if anyone is -1 on the first proposal.</div><div><br></div><div>Thanks.</div><div><br></div><div>[0] <a href="https://github.com/pulp/pulp/pull/3228">https://github.com/pulp/pulp/pull/3228</a></div><div><br></div><div>David<br></div></div></div></div></div></div>
</div>