[pmwiki-devel] PmWiki's database standard

[marc]

Hi,

I've posted a few times about the proposed PmWiki 'Database Standard', 
although I think some of these went AWOL a few weeks ago when my Gmane 
account was behaving oddly.

Anyway, I have a couple of concerns that I'd like to air.

The first point is regarding the use of ADOdb's esoteric functions. I 
think that ADOdb is a fine tool for what we are trying to achieve, 
namely a database abstraction layer. However, I believe that the use of 
its more esoteric functions is not so smart. As I've mentioned before, 
after using ADOdb for a number of years, I've now moved to ADOdb lite, 
which is indeed far, far lighter, but more than that, it is 'properly' 
constructed, so that it can be extended - in the object oriented sense.

Having converted from one to the other, I'm aware of how straightforward 
it is to reconstruct most of the more esoteric functions, although 
sometimes it might not appear to be so obvious.

For those of us committed to ADOdb lite, problems will occur should 
recipes use the esoteric functions. The only way around the problem will 
be for us to have two version of the same recipe. This doesn't seem to 
me to be very desirable,.

I would like to propose that the PmWiki database standard restricts 
itself to the use of ADOdb as a database abstraction layer, and to the 
features provides by ADOdb lite - which are a very good subset of the 
ADOdb functions, nevertheless.


Perhaps more contentiously, having examined adodb-connect.php and 
AuthUserDbase-2.0.0.php, I'm not clear why the database object is being 
passed as an array variable via PHP's globals. Is there a reason for not 
using the object?

For example, in my version of adodb-connect.php I exit as follows:

 if (is_object($DB[$dbName]))
   if ($DB[$dbName]->IsConnected())
      return $DB[$dbName];

This preserves all the other features, but ensures that the object can 
be used. It doesn't preclude the globals' use for those wanting to do 
things that way, but it might cause difficulties later with extending 
classes.

Again, for demonstration, here's my version of AuthUserDbase:

  <?php if (!defined('PmWiki')) exit();

  function AuthUserDatabase($pagename, $id, $pw, $pwlist) {
    global $AUDBaseTable;
    extract($AUDBaseTable);

    $db = ADOdbConnect($database);
    if (!$db) die($db);

    $pw = AuxNoInjection($encrypt_f($pw));
    $id = AuxNoInjection($id);

    $sql = "SELECT * FROM $user_table
            WHERE $user_field='$id'
            AND   $pw_field='$pw'
            AND   $validate_field=1";
    $rs = $db->Execute($sql);
    if (!$rs || $rs->RecordCount() < 1) return false; else return true;
}

function AuxNoInjection($value){
  return(preg_replace('/[^\w-]*/', '', $value));
}

The problem between returning an object or a boolean is obvious, of 
course. That said, perhaps we could allow adodb-connect.php to return 
objects or a boolean depending on a parameter.

It's pretty clear which way I'd prefer to go, but I'm interested to hear 
the reasons for the status quo, and what folk feel about it.

-- 
Best,
Marc