[Pulp-dev] Repo version implementation

David Davis daviddavis at redhat.com
Mon Dec 11 20:36:43 UTC 2017

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?

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.

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.

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.

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.

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.


[0] https://github.com/pulp/pulp/pull/3228

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171211/6bd86343/attachment.htm>

More information about the Pulp-dev mailing list