> That's already done and isolated in one place. You would just access myversion.content() to get a queryset, and use it like any other. There should be no need for a plugin writer to see or understand the join logic, regardless of what that logic is.
I see. As far as plugin writers are concerned, it's an implementation detail. > The other motivation was the issue of scale. Postgresql is a great database, but lots of data is lots of data. Consider a user with 10 repos, 10k content units in each, and 10 versions of each. That's a very small use case, and already would be 1M associations under option 1. As any of those numbers increase, you quickly get to hundreds of millions of associations for even a medium-sized deployment, which can have real impact on query performance, index size (you want your index in RAM when possible), index updates, not to mention the time it takes for a database backup (or restore!). So if you want to go with option 1, I encourage seeking realistic performance expectations first. Performance has a real impact on whether we retain customers.
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
