[pmwiki-users] most user-friendly method of database configuration
gmane at auxbuss.com
Sun Oct 15 12:19:00 CDT 2006
> 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
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
$dbtype = $db['moodle']->get_dbtype();
> AuthUserDBase could have
> $AUDuse = 'moodle';
> then (if $$AUDuse isn't defined...):
> $$AUDuse = new NewADOConnection($Databases[$AUDuse]['type']);
$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
> 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
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.
More information about the pmwiki-users