<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>