[wp-trac] [WordPress Trac] #26114: Auto prepare utilities for wp-db.php

[WordPress Trac]

#26114: Auto prepare utilities for wp-db.php
-----------------------------+------------------------------
 Reporter:  dougwollison     |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Database         |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  dev-feedback     |
-----------------------------+------------------------------

Comment (by dougwollison):

 Replying to [comment:1 nacin]:
 > Rather than ''new'' methods, we can use the existing ones. get_col(),
 get_var(), get_row(), and get_results() only accept two arguments: The
 query, and the output.

 Actually...
 - get_col() takes $query and $x for selecting the exact column from the
 result to return.
 - get_row() takes $query, $output, and $y for selecting the exact row from
 the result to return.
 - get_var() takes $query, $x and $y for selecting the exact field from the
 result to return.
 - get_results() could easily be modified, similar to how query() was.

 In practice I've never seen them used, but we may not want to change that.

 > If func_get_arg(1) is an array, then assume it is values to prepare and
 that func_get_arg(2) is the $output. Or, if func_get_arg(1) is
 ARRAY_N/A/OBJECT/_K, then slice off the first two arguments and let the
 function accept additional arguments the same way prepare() currently
 does.

 > We could add a third argument there, or — something I think is preferred
 — actually overload the $output argument, instead allowing an array of
 prepared values, followed by the $output argument in position three.
 > If func_get_arg(1) is an array, then assume it is values to prepare and
 that func_get_arg(2) is the $output. Or, if func_get_arg(1) is
 ARRAY_N/A/OBJECT/_K, then slice off the first two arguments and let the
 function accept additional arguments the same way prepare() currently
 does.

 That overload would certainly work, and without the slightly possible
 collision issue mine has.

 > There are a number of potential benefits to this. One, you'd always be
 preparing a complete query to be executing it, so prepared statements
 where bindings happen server-side (like PDO proper or mysqli) could be
 used. We could then cache that inside wpdb, thus enabling future queries
 with the same signature to be re-executed with new values.

 Not sure if I follow...

 > Two, which is more practical and less theoretical, you'd be able to
 actually make decisions based on a query's "signature" (a query minus the
 prepared values). Example: Filtering all queries of a particular
 signature, or invalidating the cache of an entire group of queries.

 True; we should add a filter to the prepare method before it runs it
 through vsprintf.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/26114#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software