I'd appreciate suggestions on how to implement the query log for devel.module now that the new DB layer has landed. I've already submitted a patch to add timing info: http://drupal.org/node/298669 But, it seems that PDO will not show us the SQL that was executed for any given prepared statement. We have access to the statement with placeholders, but that can be verbose as sin, and can't be copy/pasted into a console. Here is a statement for cache_set(): INSERT INTO {cache_registry} (serialized, created, expire, headers, DATA, cid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5) ON DUPLICATE KEY UPDATE serialized=:db_update_placeholder_0, created=:db_update_placeholder_1, expire=:db_update_placeholder_2, headers=:db_update_placeholder_3, DATA=:db_update_placeholder_4 Not so readable, eh? So, should we grab the executed SQL from the DB itself? I had some success with mysql SHOW PROFILES command - http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html. In order to fully implement that, I need a hook before and after the query is executed so i can start and stop profiling. The profiler will only log 100 queries at a time and our pages require more than that. Other DB backends would need a different approach.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moshe Weitzman schrieb:
I'd appreciate suggestions on how to implement the query log for devel.module now that the new DB layer has landed. I've already submitted a patch to add timing info: http://drupal.org/node/298669
But, it seems that PDO will not show us the SQL that was executed for any given prepared statement. We have access to the statement with placeholders, but that can be verbose as sin, and can't be copy/pasted into a console. Here is a statement for cache_set():
INSERT INTO {cache_registry} (serialized, created, expire, headers, DATA, cid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5) ON DUPLICATE KEY UPDATE serialized=:db_update_placeholder_0, created=:db_update_placeholder_1, expire=:db_update_placeholder_2, headers=:db_update_placeholder_3, DATA=:db_update_placeholder_4
Not so readable, eh?
If you just replace db_update_placeholder by something shorter, it wouldn't be a problem, I think. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIrvyffg6TFvELooQRAqBJAJ9nCCW04gAfgFExBAjzC9yB5/O+qQCfWMRC sEPoBQkhK2BqocOW7vhmVmU= =9Ymo -----END PGP SIGNATURE-----
On Fri, 22 Aug 2008 19:51:28 +0200, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moshe Weitzman schrieb:
I'd appreciate suggestions on how to implement the query log for devel.module now that the new DB layer has landed. I've already submitted a patch to add timing info: http://drupal.org/node/298669
But, it seems that PDO will not show us the SQL that was executed for any given prepared statement. We have access to the statement with placeholders, but that can be verbose as sin, and can't be copy/pasted into a console. Here is a statement for cache_set():
INSERT INTO {cache_registry} (serialized, created, expire, headers, DATA, cid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5) ON DUPLICATE KEY UPDATE serialized=:db_update_placeholder_0, created=:db_update_placeholder_1, expire=:db_update_placeholder_2, headers=:db_update_placeholder_3, DATA=:db_update_placeholder_4
Not so readable, eh?
If you just replace db_update_placeholder by something shorter, it wouldn't be a problem, I think.
Cheers, Gerhard
I don't know that using a shorter string would be much help, especially when the above is a generated query. For static queries you run into the same issue. However, if someone is using named parameters instead of ? placeholders then perhaps we can simply do a strtr()? Hm, that wouldn't handle quoting/escaping, though. That may be a better way to go. (Store the query and the args separately, then merge them back together on rendering.) --Larry Garfield
However, if someone is using named parameters instead of ? placeholders then perhaps we can simply do a strtr()? Hm, that wouldn't handle quoting/escaping, though. That may be a better way to go. (Store the query and the args separately, then merge them back together on rendering.)
Right. Seems like devel can ask for quoting via PDO::quote and then strtr(). See http://www.phpbuilder.com/manual/en/function.pdo-quote.php.
participants (3)
-
Gerhard Killesreiter -
Larry Garfield -
Moshe Weitzman