Among the three tools that I chose to test, ADODb was certainly the most used by me, although always associated with other helper tools. Sadly, my respect for this component has fallen deeply after completing my tests.

The beginning of this process occurred with the opening of its source code, developed entirely in PHP 4, though it may detect PHP 5 and enable the using of PDO drivers. In theory, this explains the rarity of object-oriented code, mostly replaced by functions filled with globals, but does not justify the messy files. Business rules are virtually unreadable and lost amid commented debugs. Indentation is made with tabs, and there are tips in the documentation suggesting the configuration of your text editor for better viewing. I mean it. Really.

Maintenance must be extremely complex, given the poor design that, if was not a choice, eventually became a need to continue the project over the years. With a multitude of passed-by-reference variables, tests must not be very common before new releases.

Another curious factor is speed. Even though it is something I can not complain about, sounds absurd to read documentation excerpts which proudly presents an out-of-date benchmark from 2003.

(Note: The database table used here was described in the introduction post)

Using

To start, you need to include a single file.

include('adodb5/adodb.inc.php');
 
// not needed, but only way to raise exceptions
include('adodb5/adodb-exceptions.inc.php');

Connection

As we are working with PDO, an ADODB_pdo object is obtained through a call to ADONewConnection with a DSN string as argument. In this case, the connection is made automatically.

try {
    $db = ADONewConnection("pdo_mysql://me:secret@localhost/shop");
 
    // for non-PDO drivers
    // $db->connect('localhost', 'me', 'secret', 'shop'); 
} catch (Exception $e) {
    throw $e;
}

Debugging

There is a flag which displays the DBMS driver and the SQL each time execute() method is called.

$db->debug = true;

Fetch mode

The format of the array containing the result set of your data retrieval query is directly related to the driver you are connected with. Depending on your choice, you should get numeric and/or associative indexes for every column. You can force indexing type using setFetchMode().

$db->setFetchMode(ADODB_FETCH_ASSOC);

Executing queries

Unlike what you can see on Doctrine, ADODb does not have specific methods for generating INSERT, UPDATE, and DELETE queries. All theses SQL statements must be filled in execute() method (or build in autoExecute()), which returns in this case and object of type ADORecordSet_pdo.

$rs = $db->execute('select * from customer');
 
// If you're not using adodb-exceptions.inc.php, you can test the return this way
if (!$rs) {
    echo $db->errorMsg();
} else {
    echo $rs->recordCount() . ' rows found <br/>'; // return -1 if cannot be determined
    while (!$rs->EOF) {
        print_r($rs->fields);
        $rs->moveNext();
        echo '<br/>';
    }
}

In data manipulation queries, you can get the number of affected rows after its execution.

$rs = $db->execute('DELETE FROM customer WHERE last_name = "Secrieru"');
$affectedRows = $db->affected_rows();

Conclusion

This is an outdated solution that was interesting in a time whenthere was fewer options and possibly no concerns with standards, best practices or design. I can not see it as a big competitor to other tools of the same type. The documentation is awfully unclear and poorly structured. In this example which features the use of autoExecute() method, it is possible to see this sentence: “The rest of this section is out-of-date”.

Visibly more limited than Doctrine, ADODb 5.11 was not an exciting experience. Although it does its job of abstracting the database layer without major complications and very few challenges, it seems unwise to start a project using it.