Comment 7 for bug 709172

The best model for supporting this would seem to be to have a new model, SoftwareItemInRepository or something, which would basically have a software_item, a repository, and review stats aggregation info. I think it would be best if Reviews then drops the 'repository' foreign key and replace 'softwareitem' for a foreign key to SoftwareItemInRepository (or whatever it's called :) ). We can then aggregate stats on both SoftwareItemInRepo and SoftwareItem (for when stats are requested across all origins and distroseries).

Thinking this over, this will still cause us to have server-side processing when all reviews for a certain origin but all distroseries are requested, for instance. To avoid that completely we could add *two* new models, one that adds the origin to SoftwareItemIn, the other that adds the distroseries, and aggregate stats on all three of these. Also we'd need to only allow stats to be requested for all distroseries in an origin, not the other way around (I don't even know if requesting stats for all origins with a certain distroseries makes sense). Then again, this is a model change that could be implemented after we've settled on the api we need, if we find the stats-processing load is too much.