[wp-trac] [WordPress Trac] #54042: Extending wpdb::prepare() to support IN() operator

WordPress Trac noreply at wordpress.org
Mon Jul 31 09:40:32 UTC 2023


#54042: Extending wpdb::prepare() to support IN() operator
-------------------------------------------------+-------------------------
 Reporter:  craigfrancis                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Database                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback needs-        |     Focuses:
  testing early has-unit-tests                   |
-------------------------------------------------+-------------------------

Comment (by craigfrancis):

 I think I need some direction/help with this one.

 My [https://github.com/WordPress/wordpress-develop/pull/2191/files basic
 patch] is fairly simple, but it has problems with argnums, e.g.

 {{{#!php
 <?php
 $wpdb->prepare(
     'WHERE id IN (%...d) AND (name = "%3$s" OR name = "%2$s")',
     [
       [1, 2, 3],
       'A',
       'B'
     ] );

 // WHERE id IN (1,2,3) AND (name = "3" OR name = "2")
 }}}

 Because `%...d` can hold many values, the later placeholders need their
 argnums updated (insert my usual complaints about these placeholders being
 un-quoted); and it doesn't support modifiers (ref @jrf, "using %04d to get
 0 padded numbers in the replacement values"), e.g. `%...04d`.

 I started putting together a second patch, it supports modifiers, and re-
 indexing argnums, but it's a bit more complex, and has a performance
 impact (admittedly in the range of fractions of a millisecond, but it can
 be 20% slower, e.g. 0.00248 ms to 0.00296 ms).

 I've got a [https://wpdb.eiv.dev/ testing page], where tests `009` and
 later show the new functionality (patches can be found at the bottom of
 the page).

 Am I being too concerned? is there a simpler way of doing this?

 (while I dislike complexity, I'd rather have it here, where it can be well
 tested, instead of the current approach of developers writing
 [https://github.com/WordPress/WordPress-Coding-
 Standards/blob/efbaa1df3cd584418a8908e0340f3b83d41b7cd1/WordPress/Tests/DB/PreparedSQLPlaceholdersUnitTest.inc#L70
 complex code] themselves, and we hope they never make a mistake).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54042#comment:39>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list