Hi Robert, While reading your report it struck me that although we now have a test asserting the number of DB queries issued by that page (you added one, I guess?), the code that might trigger these queries is still scattered all around, making it tedious (as you described) for someone to map issued queries to the code issuing them. IOW, we're less likely to see this page regressing and issuing lots more queries, but it's still a significant amount of work just to find the bits that still need to be optimized.
Wouldn't it be nice if all the code doing DB access was in a single place so someone could start by guessing which piece of code was issuing certain queries, drop into the debugger just to assert that and then move on to optimize it? We should be able to do that by having just a single view method (obviously calling other helper methods) which fetches and prepares all the data to be used when rendering the view, and then a test asserting that all the queries issued by the page are actually issued within that method. If we want we can go a step further and somehow mark these views so that the transaction is automatically doomed (or something like that) after the fetch/prepare method is called. What do you think? -- Guilherme Salgado <https://launchpad.net/~salgado>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
