The current code turns off all query generation in update.php, but it would be nice to be able to see queries there when debugging update functions. Moshe indicated this might be best be done by turning on the option to store queries and add register shutdown back in for the update.php file, adapting it so it stores the queries but does not display them to the page.
That much is relatively easy to do, but what would be even better would be to store the queries, then display all of them on the last page of update.php so you can see everything that has happened.
I spent quite a bit of time trying to figure out how that could be done, but couldn't get it working, so I'll submit it as a feature request here in case someone else is interested and can see how to do it.
One final thing I noticed is that the stored queries don't have parameter substitutions in them, they just look like "UPDATE {node} SET nid=D where type=S". I would rather see the query with all its substitutions since the problem I am debugging is often that the wrong thing got substituted in.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | devel.module_15.patch | 2.61 KB | karens |
Comments
Comment #1
dwwI think this would be a handy feature, too, but I have no time to write any code for this, sorry.
Off topic, but...
You realize update_sql() doesn't do substitutions, right? :( This is a nearly critical bug in the DB API, if you ask me. Countless hours of developer time have been wasted and probably dozens (if not hundreds) of bugs have been caused by this. See http://drupal.org/node/36324
Comment #2
karens commentedYes I know about update_sql, but the devel module doesn't seem to store substitutions for db_query() either. It just swaps in 'D' or 'S' or whatever. The substitutions are in the queries when displayed in the footer, so it's something different done when the queries are stored instead of displayed.
And I agree we should do something about update_sql(), too, but as you said, that's off topic.
Comment #3
moshe weitzman commented@karen - It does that subsitution because thats usually what you want when analyzing slow queries. You want ones that happen often and are slow and removing the data fro mthe query lets you actually count how often queries occur. We had not foreseen using 'stored' in the way proposed here. maybe we should store them in the SESSION for display on the final update page. Alas, I can't dig into this now either.
Comment #4
karens commentedWell I put together something that seems like it ought to work, but it doesn't. I store the queries in a $_SESSION until the final page, then print them. But for some reason it isn't bringing in all the intermediate queries.
Comment #5
salvisD5 is obsolete.