Edit report at https://pear.php.net/bugs/bug.php?id=11103&edit=1
ID: 11103
Updated by: daniel.oconnor@gmail.com
Reported By: copong at gmail dot com
Summary: Have access to the actual SQL query performed
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package: DB_DataObject
Operating System: Linux
Package Version: 1.8.5
PHP Version: 5.2.1
Roadmap Versions:
New Comment:
-Status: Feedback
+Status: No Feedback
Previous Comments:
------------------------------------------------------------------------
[2008-01-29 21:38:47] alan_k
patch is broken - but we cant really add object vars - especially when
they may overlap with database col names.
I suspect the best answer to this problem is
findGetQuery() - which returns the $sql var.. - which can then be used
by find().
putting queries called into
$GLOBALS['_DB_DATAOBJECT']['QUERYLOG'] = array()
based on
options['log_queries'] settings would be the best way to log it.. (and
probably more usefull..)
------------------------------------------------------------------------
[2007-05-23 08:01:55] #d2de8c5635353c9292f
Description:
------------
I wanted to perform a subquery and I wanted to construct the subquery
using DB_DataObject; however I could not find a public var on the class
that allowed me to have access to the actual SQL statement (I mean, an
actual STRING containing the query itself). I have created a patch that
allows this for the last stable version of DB_DataObject.
* A new public var, $sql, is created.
* A new function, sql($n = false), is created. Here $sql will be set.
* The function find($n = false) is refactored.
Long story short, I stripped all the code in find() that creates the SQL
query, put it apart on another function and avoided code duplication by
making find() use this new function.
So you can use $object->sql(); and $object->sql will be populated with a
SQL statement.
Please see attached diff.
------------------------------------------------------------------------