Create new Query Diff tab

[leonidasmi]

Disclaimer: This is a POC and not a finished product. The code has been briefly validated, but may very well lack proper security, privacy or performance measures.

Context

• This is regarding this feature request
  • Adds a query diff tab under the database queries tab.
  • The new query diff tab is populated by a diff of queries between page loads whenever we refresh a page.
  • That way, developers have an easy visual to understand whether their current work has resulted in performing regressions or improvements.

Relevant technical choices:

• I went with storing the query signatures in session storage instead of using the database, mostly because of privacy concerns in sites with multiple users.
• The feature is getting enabled only when the user opens the new Query Diff panel. Two notes:
  • We did this to reduce the impact by avoiding storing the queries snapshot on page load. If we think doing that is fine, we can add a side effect in the DOMContentLoaded handler that populates the snapshot.
  • We can improve this by:
    • Make opening the Database Queries panel the trigger for this
    • Make it clearer to the user of this, to avoid confusion
• Instead of giving queries_diff it's own panel menu, to avoid creating a new collector I added the new feature as a child of the DB Queries panel menu. That way, I just re-use the db_queries collector.

How to use:

• Enable: Go to QM Settings → Query Diff → check "Enable query diff tracking"
• Trigger storage: Go to the Query Diff panel
• First load: Queries are captured and stored in sessionStorage
• Refresh: Current queries are compared against stored queries
• Diff panel: Appears below the Database Queries table showing:
  • Summary (previous count → current count)
  • Added queries (with SQL and caller)
  • Removed queries (with SQL and caller)

Possible next steps:

• Consider having a more flexible query comparison, by replacing values with placeholders
  • Could make the implementation more hardened for storing sensitive data
  • Would also reduce the noise (false positives) when queries are largely the same (eg. we shouldnt care if the UPDATE `wp_usermeta` SET `meta_value` = '1770383389' WHERE `user_id` = 1 AND `meta_key` = 'wc_last_active' query is repeated with different meta values
• Add time expiration in the session storage
• Verify the logic of calculating and diff-ing query snapshots - there might be performance chances there (and edge-case bugs)

Acceptance Test Instructions

Toggling the new setting

• Go to a frontend page and open the QM panels
• Confirm that you dont see in the local storage of your browser (via the Application tab in dev tools), that there's no qm-query-diff-enabled entry.
• Enable the Enable query diff tracking setting
  • Confirm that you now see a qm-query-diff-enabled entry in local storage and it is true.
  • Open the Query Diff panel and confirm that you now see the qm-query-diff-data entry in the session storage
    • NOTE: we can improve this, so that we can make opening the Database Queries panel the trigger to fill in the session storage
  • Confirm that you see the qm-query-diff-data entry in the session storage data via the Application tab in dev tools
• Go to the settings and disable the Enable query diff tracking setting
  • Confirm that you see no qm-query-diff-data entries anymore in the session storage data
  • Also confirm that you no longer see the qm-query-diff-enabled entry as true in your local storage. It should be false now.

Moving to a different page:

• While having the setting enabled, visit the Query Diff panel and confirm that the qm-query-diff-data entry in the session storage has a URL attribute that's equal to the current page's URL
  • Go to a different page and once loaded, confirm that the that the qm-query-diff-data entry in the session storage has been updates so the URL attribute is now equal to the new page's URL
  • Confirm that you get a Refresh this page to compare queries between page loads message in the Query Diff panel.

[johnbillion]

This looks interesting!

I will say that this is probably best done properly once version 4 is out and we've switched to rendering the panels with Preact and gotten rid of the jQuery soup. But I like the idea a lot.

[leonidasmi]

Glad you like it!

I'll come back to it once v4 is out, good luck with that.

[leonidasmi]

By the way, I'd love to take a stab at it now, even if 4.0.0 isn't out, if you think it's not a terribly bad idea.

For that, I can branch out of release-4.0.0-alpha.2 and (slowly) port what I have here into the new rendering logic.

[johnbillion]

It's up to you. The branch is fairly stable now (although I still need to make changes to the way stack traces are recorded) but I've not written much documentation yet. Data collection hasn't really changed but the CONTRIBUTING.md file details how the data classes are now generated and passed from php to react.