<div dir="ltr"><div>> 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.</div><div><br></div><div>I see. As far as plugin writers are concerned, it's an implementation detail.</div><div><br></div><div>> 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.</div><div><br></div><div>Performance has a real impact on whether we retain customers.<br></div></div>