~~This changes the behavior in the case where both an rpmID and an archiveID is given. Before these conditions were effectively ORed, because the second stanza would add to candidate_buildroot_ids. With this change, if rpmID is given and that first stanza yields no buildroots, then we return None, even if the archiveID param might yield some.~~

~~Granted, I'm not 100% what we should be doing when both are given, or if we even really want to support that.~~

Nevermind, I think I'm reading this wrong

Looking at this, I realize that the original optimization from #2074 leaves the original joins and clauses in place for the rpmID and archiveID cases, even though they are essentially obsoleted.

This means two things,

• In the "not used in buildroot" case this PR is addressing, the behavior should be no worse than before #2074
• In these cases, we are still performing these joins, which seems like a potential performance hit.

Granted, we do need to perform the join to return the is_update field in the rpmID case (though I wonder if we actually need that field). Otoh, the join in the archiveID case seems entirely redundant.

I guess we do not have to address the above here, though. This fix looks fine. We just might want to follow up.

:thumbsup:

Commit 9fa07f65 fixes this pull-request

I've filed #2300 for the follow up