[pmwiki-devel] PmWiki's database standard

[marc]

Ben Stallings said...
> Marc wrote,

Thanks, Ben. My thought was to start a debate about whether what was 
proposed, which we all agree is a good idea, is being implemented in the 
most appropriate way.

>  > The first point is regarding the use of ADOdb's esoteric functions.
> 
> OK, I give up, which ones are more esoteric?  Do you mean all functions 
> that are not included in the lite version

Yes. There aren't that many, though, that are likely to be used, imo.

> or some subset of those?  I'm 
> not sure whether the functions I'm using are ones you consider esoteric 
> or not, so please clarify.

All I can do is point to the ADOdb lite docs, which specify what has 
been implemented, rather than replicate them here

  http://adodblite.sourceforge.net/functions.php
  http://adodblite.sourceforge.net/modules.php

As I mentioned, I've used ADOdb for years, and the only function that 
needed replacing was GetUpdateSQL(). This is easily replaced by a 
regular SQL UPDATE.
 
> It seems to me that there could be multiple versions of the Database 
> Standard file for sites using ADOdb, ADOdb-lite, or even PEAR; or that 
> all three of those could be put into one PHP function with the 
> $ADOdbLocation global or its equivalent telling the function which 
> standard to use.  The important thing as I see it is to get the 
> connection routines out of the individual recipes in order to prevent 
> duplicate connections.  I'm not keen on telling recipe authors which 
> functions they can and cannot use; I'll leave that to someone with more 
> credibility.

I agree that any of the available mechanisms can be used, but there is 
an issue should a recipe designer use a function not supported by one of 
the abstraction layers.
 
> > 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?
> 
> Yes there is, thanks for asking.  The reasoning was that the 
> ADOdbConnect() function returns either true or an error message to be 
> handled by the recipe that calls the function, since adodb-connect.php 
> does not have any user interface of its own and hence no error handling. 
>   If it returned an object instead of true, each recipe that uses the 
> function would have to test whether or not the result is an object 
> before handling the error message.

Okay, I can see the intent, but

  if (!is_object($DB[$dbName]))
    return "Unable to connect to database: ".$DB[$dbName]->ErrorMsg();

won't work because it calls a method on an object that doesn't exist.

You need to be a bit careful too, because you are using both

  ADONewConnection($dsn) and $DB[$dbName]->Connect

Both return true/false, but the former doesn't create an object when it 
fails (it does when using ADONewConnection($driver)) while the latter is 
acting on an instantiated object (which it doesn't destroy if it fails).

This

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

handles all the eventualities, and as you say, the recipe writer can do:

  $db = ADOdbConnect($database);
  if (!$db) return false; # or whatever
 
> Also, the purpose of the function is to provide a standard API for 
> databases

Indeed.

> and a global variable ensures that any time a recipe refers 
> to $DB, it's the same $DB that other recipes are using.

None of this goes away, but it is transparent when using objects. In 
other words calling:

  $db = ADOdbConnect($database);

does

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

I've found using the db objects as objects much simpler.

-- 
Best,
Marc