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
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

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.


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
postedJan 27, '12 at 1:19p
activeJan 27, '12 at 1:19p

1 user in discussion

Daniel Oconnor: 1 post



site design / logo © 2022 Grokbase