Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
issues for PDO / PDO-like DB wrappers
03-31-2014, 10:14 PM
Post: #1
issues for PDO / PDO-like DB wrappers
Hey there, I'm committing a PDO_mysql database connector into the working copy.

Some issues: DB_data_seek() doesn't work properly for PDO. It's emulated by fetching all the rows and then returning the desired row. This is obviously inefficient, and 99% of the time DB_data_seek() is used to return to the first row, just to get the first rows results. I suggest rewriting the code to avoid the need to return to the first row in the first place-- aka trying not to rely on DB_data_seek(). It's not possible to move the pointer with PDO Mysql so it's just not going to work properly (although it could theoretically be implemented with other DB's the installation code has mysql-specific code right now, so other installations can't be supported yet)

Similarly, DB_num_rows() doesn't work properly with PDO. It works for MySQL but is not guaranteed to work for other DB's. Usually but not always it is used to check if results were returned. I suggest using columnCount (mysqli->field_count) which will be > 1 if there is a result set. For the 2 or 3 legitimate uses of DB_num_rows() to count the number of rows, I'd suggest using an iterator instead.

Also, DB_fetch_row and DB_fetch_array are not used consistently, sometimes DB_fetch_row expects an associative array of field names, sometimes a numeric zero-based array, the same for DB_fetch_array. I recommend DB_fetch_row expecting both, and DB_fetch_array expecting a zero-based array only.
Find all posts by this user
Quote this message in a reply
04-04-2014, 12:32 PM
Post: #2
RE: issues for PDO / PDO-like DB wrappers
DB_fetch_row - always expects a non-associative array ... I think so the index is always 0,1,2...etc
DB_fetch_array - always returns an associative array with nice names as indexes we are trying to move to this function in 99% of places.
Seems like a show stopper for PDO if it is not capable of reproducing basic functions that are necessary in webERP code - not sure it is worth a re-write to be PDO capable?

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
Quote this message in a reply
04-04-2014, 02:33 PM (This post was last modified: 04-04-2014 02:36 PM by serakfalcon.)
Post: #3
RE: issues for PDO / PDO-like DB wrappers
It's completely capable, just inefficient.

Those 'basic functions' are relying on the particular way that mysqli works, which is different from many other db wrappers. PDO is a big use-case but there are others. I thought we were concerned about platform independence?

It's possible to rewrite almost all of the calls to DB_num_rows() as a simple check if there is data (DB_has_rows() as a check for if the data has columns could work equally fast for pretty much any db wrapper for example).

DB_data_seek isn't used much, but most of the time it's used to return to the first row. It's inefficient the way I've written the PDO extension now, but it works. It wouldn't be necessary to use it at all for most cases if the information from the first row was stored in a variable and used later.
(04-04-2014 12:32 PM)phil Wrote:  DB_fetch_row - always expects a non-associative array ... I think so the index is always 0,1,2...etc
DB_fetch_array - always returns an associative array with nice names as indexes we are trying to move to this function in 99% of places.
Seems like a show stopper for PDO if it is not capable of reproducing basic functions that are necessary in webERP code - not sure it is worth a re-write to be PDO capable?

OK I am for the switch away from DB_fetch_row if that is the case, there are a few cases where they are used inconsistent with this, but the code works since mysqli gives back both associative and numeric keys by default. When I tried strictly typing to associative or numeric it caused problems, but we can sort that out if we're rewriting anyway.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: