Still, if we're mostly ignoring the outliers for now and thinking
about
the 'normal' cases, I think I'd contend that getting 140 results at a
time should be a pretty 'normal' use case for something like resultsdb.
I'm not sure I'm a fan of doing something more complex than the
'scenario' key if the goal is purely to try and reduce the number of
results that actually need to be returned by the server in the first
place from, say, 200 to 50. That's just MHO, though. :)
We can try this and see. So if we decided to just get all results, and ignore those which
happen to have too many of them, this could be the reasonable approach from Bodhi:
1. Query /results?item=NVR
2. Add &since= based on last Bodhi update modification timestamp (for bodhi_update
type) or earliest Koji build timestamp (for koji_build type, if not difficult)
3. Add &limit= with some reasonable number based on our current db stats (probably
something between 50 and 100)
4. Stop loading additional pages if it seems there's too much data (e.g. give up after
&page=4 -> 500 results)
5. Deduplicate the results based on scenario in Bodhi (server or web browser)
6. For some items, Bodhi will not be able to display results. It should display some
explanation message instead (it can advise people to go to resultsdb_frontend and query
for a specific testcase result if they're interested).
We should on course still get a better hosting for our production DB. If the combination
of these doesn't help with performance, or the db data explode with depcheck-style
results, or we get more requests for /latest endpoint while understanding scenario,
we'd have to come up with the middleware mentioned before.
Does that sound reasonable?