Returns the SQL that would be executed for the current query.
The bindings for the query are represented by question marks (?
) just as when using queryExecute
. qb can replace each question mark with the corresponding cfqueryparam
-compatible struct by passing showBindings = true
to the method.
If you want to show the SQL that would be executed for the update
, insert
, updateOrInsert
, or delete
methods, you can pass a toSQL = true
flag to those methods. Please see those individual methods for more information.
To get back a SQL string that can be copied and pasted into a SQL client to run can be retrieved by passing showBindings = "inline"
.
Executes a callback with a clone of the current query passed to it. Any changes to the passed query is ignored and the original query returned.
While not strictly a debugging method, tap
makes it easy to see the changes to a query after each call without introducing temporary variables.
A shortcut for the most common use case of tap
. This forwards on the SQL for the current query to writeDump
. You can pass along any writeDump
argument to dump
and it will be forward on. Additionally, the showBindings
argument will be forwarded on to the toSQL
call.
A QueryBuilder
instance can be put into pretend mode by calling the pretend
method. In this mode, the QueryBuilder
will turn all query operations into no-ops. A log of the SQL that would have been executed can be retrieved from the query log.
Once a QueryBuilder
instance has been set to pretend mode, it cannot be unset. Instead, you will need to obtain a new query.
Each instance of a QueryBuilder
maintains a log of queries it executed. This can be accessed by calling getQueryLog
. This will return an array of structs like so:
This can be very useful in combination with the pretend
feature to see what SQL will be executed before actually executing it.
You can add contextual information as a comment to all executed queries using sqlCommenter, a specification from Google.
For more information, check out the dedicated sqlCommenter page.
Starting in cbDebugger 2.0.0 you can view all your qb queries for a request. This is enabled by default if you have qb installed. Make sure your debug output is configured correctly and scroll to the bottom of the page to find the debug output.
qb is set to log all queries to a debug log out of the box. To enable this behavior, configure LogBox to allow debug logging from qb's grammar classes.
qb can be quite chatty when executing many database queries. Make sure that this logging is only enabled for your development environments using ColdBox's environment controls.
ColdBox Interception Points can also be used for logging, though you may find it easier to use LogBox. See the documentation for qb's Interception Points for more information.
Name
Type
Required
Default
Description
showBindings
boolean | string
false
false
If true
, the bindings for the query will be substituted back in where the question marks (?
) appear as cfqueryparam
structs. If inline
, the binding value will be substituted back creating a query that can be copy and pasted to run in a SQL client.
Name
Type
Required
Default
Description
callback
Function
true
A function to execute with a clone of the current query.
Name
Type
Required
Default
Description
showBindings
boolean | string
false
false
If true
, the bindings for the query will be substituted back in where the question marks (?
) appear as cfqueryparam
structs. If inline
, the binding value will be substituted back creating a query that can be copy and pasted to run in a SQL client.
qb supports the sqlCommenter specification by Google for appending contextual information to executed queries.
sqlCommenter support is off by default, but can be activated by setting the sqlCommenter.enabled
setting.
Once enabled, qb will append a comment on to every non-commented query. This happens as the query is ran, so you will not see this output when calling toSQL()
or dump()
.
sqlCommenter will only add a comment to non-commented queries. If you query contains a comment anywhere in it, sqlCommenter will ignore it.
An example query with a sqlCommenter comment looks like this:
The default configuration structure for sqlCommenter is as follows:
When the enabled
flag is false
, no comments will be appended.
The commenters
array are the different components that will add contextual information to each query. You define them by defining a struct with a class
key pointing to a WireBox mapping and a properties
key containing a struct of any necessary properties.
Each Commenter must implement the ICommenter
interface. (The implements
keyword is not required.). They will be called with the sql
being commented and the current datasource
. It should return a struct of key/value pairs that will become comments.
Here is an example of the FrameworkCommenter@qb
:
You may use any. all, or none of the commenters
provided by qb. You may also create your own for your application. You may even see commenters pop up on ForgeBox for popular use cases.
For example, if you use cbauth
(or cbsecurity
using cbauth
), this commenter will add the current user ID to each query.
The comment generated by sqlCommenter is escaped and url-encoded. It can be reversed by calling the SQLCommenter.parseCommentedSQL
method with the full query or the SQLCommenter.parseCommentString
method with just the comment.
Parses a commented SQL string into the SQL and a struct of the key/value pair comments.
Parses a comment string into a struct.
Out of the box, qb includes a ColdBoxSQLCommenter
. Since sqlCommenter adds contextual information, some level of framework or application integration is necessary. You can create your own sqlCommenter
instance by extending the qb.models.SQLCommenter.SQLCommenter
abstract component. If you create a SQLCommenter
for a specific framework, consider sharing it with others on ForgeBox.
Name
Type
Required
Default
Description
sql
string
true
The commented SQL string to parse.
Name
Type
Required
Default
Description
commentString
string
true
The comment string to parse into a struct.