[pmwiki-users] most user-friendly method of database configuration

marc gmane at auxbuss.com
Sun Oct 15 12:19:00 CDT 2006


Crisses said...

> One thing I notice while working on recipes is the (occasional)  
> repetition of the same database connection data.  And maybe while  
> we're discussing a method of similar database abstraction (adodb) we  
> should discuss a way to not have unnecessary repetition of database  
> login info, while still allowing admins to access different databases  
> if they want to.  For example, maybe your pagestore is on the same  
> server, maybe even the same database, as the authentication that  
> would be accessed by AuthUserDBase.  Why would the admin repeat the  
> info?

I agree. My recipe collection runs parallel to the released recipes for 
just this reason.

(I'd also like to see the adoption of phpmailer too, btw.)

> Having a unique human-readable label for each database (and database  
> connection!) would be helpful here.  PHP has this wonderful way of  
> allowing you to call function and name names by way of variables.
> $Databases['moodle'] = array(connection info...); //  $Databases 
> ['moodle']['type'] is "mysql"

Why not an array of db objects? Then 'type' is just an attribute of the 
object.

  $dbtype = $db['moodle']->get_dbtype();

> AuthUserDBase could have
> $AUDuse = 'moodle';
> 
> then (if $$AUDuse isn't defined...):
> $$AUDuse = new NewADOConnection($Databases[$AUDuse]['type']);

  if(!is_object($db['moodle']))
    $db['moodle'] = new db(blah);

> "there can only be one connection to a given  
> database at a time" -- this is not true.  I can easily do $db1 and  
> $db2 as two connections, perhaps each looking at a different table of  
> the same database...

I presume you mean queries rather than tables. But, in any case, you can 
have multiple result sets on a single connection, because ADOdb returns 
an ADORecordSet object. A single connection for our purposes should be 
sufficient, imo.

> If I'm authenticating someone from tableA and you're storing pages in  
> tableB of the same database, we could share the same connection/data  
> -- or we can have multiple connections and duplicated authentication  
> data.  

If you're simply reading, then there is no issue. It's a bit more tricky 
with writing, because transactions might come into play. And transaction 
commands and handling varies between database types.

> Why are  
> admins required to duplicate their data because the cookbook authors  
> can't agree on one method to share this data (and maybe even  
> connection!) between their recipes?

Probably because Patrick hasn't taken it under his wing.

Perhaps it's time that we waved the flag of recipe interoperability for 
the attention of his benevolent dictatorishness.

> Whatever we do, we have to allow multiple databases and servers while  
> making it easier on the administrator(s).

I agree, but I don't believe it's hard to do - for typical PmWiki 
requirements. Just needs some thought and agreement.

-- 
Best,
Marc





More information about the pmwiki-users mailing list