[wp-trac] [WordPress Trac] #21663: Use PDO for MySQL queries when PDO is available

[WordPress Trac]

#21663: Use PDO for MySQL queries when PDO is available
------------------------------------+------------------------------
 Reporter:  scottconnerly           |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Database                |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+------------------------------

Comment (by hakre):

 If you go the driver route, you should reduce duplicate code between those
 classes, e.g. to have that in a (abstract?) base class.

 Also I'd say there is pretty much an overhead through the level of
 indirection by having "drivers". I mean PHP offers this Drivers Thingy
 with PDO, no need to re-invent the wheel technically - just to integrate
 PDO which is already driver based.

 Just while I've quickly seen it in the patch: For the PDO Driver, keep in
 mind that the DSN can be an alias. You can not just convert host /
 database / username / password here into a DSN like in the patch. Also
 you've hardencoded the actual PDO driver. That's limiting the use of a PDO
 based database class for no reason. Just saying, what jumps into my sight,
 it's maybe too early for concrete feedback at all.


 To reduce the levels of indirection, it is probably more straight forward
 to offer a set of default database classes that Wordpress can load (by
 configuration). If you work with Interfaces, it is not important any
 longer if that included database class then is having a full blown driver
 implementation loading diverse drivers or is just a straight-forward
 database class as we have it since years (and as we love it). The legacy
 database class then can become the blueprint for the interface.

 Next generation classes could implement and interface that extends from
 the legacy one (to deal with the problems the original implementation has,
 or at least to offer some way to deal with it).

 Also I suggest you leave warnings all over the place that the prepare
 function is misnamed. I've seen on the Wordpress dev blog that users are
 being told this is the way to "prepare" just not so long ago, but the
 prepare function actually just verifies and sanitizes the first string
 parameter (the query) and then does some dumb stuff on the passed array
 that should represent values. This is the exact opposite of what prepared
 and parametrized queries are.

 If you want to improve things, start there offering an additional function
 that follows common parametric queries patterns so that it's not such a
 burden to go there with a Mysqli / PDO based class. The escape route is
 not used by a driver based abstraction, like PDO demonstrates.

 Otherwise, this all might just not be worth the work because even as of
 today, you can simply replace the database class with the taste you like
 most.

 Just my 2 cents.

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