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

[Crisses]

On Oct 14, 2006, at 4:33 PM, Ben Stallings wrote:
> Crisses wrote:
>> You need an identifier though.  A nickname.  Because what if  
>> (gasp) you have multiple mysql databases?  ADODB is database  
>> agnostic, so use an agnostic method of addressing the database  
>> definitions -- then they can be on any server, and multiple of the  
>> same type -- or from the same program -- can be used:
>> $DQConnections['moodleA'] = array ();
>>
>> They're not much different from one another, just keep in mind  
>> that you do need to give each database setting a unique name.
>
> Each database already has a name; that's one of the parameters that  
> has to be passed in order to make the connection.  Giving another  
> name to the connection would be redundant, since there can be only  
> one connection to a given database at a time, and it would also be  
> transient, since $WikiLibDirs is an array of unnamed objects.
>
> Besides, if admins add objects to $WikiLibDirs themselves, rather  
> than relying on the script to do it, they will have the intriguing  
> option of overwriting the default PageStore ($WikiLibDirs[0]) and  
> thereby making their wikis database-driven... not that there's  
> anything wrong with flat files at all, but if hypothetically you  
> wanted a database-driven PmWiki, all you'd have to do is overwrite  
> the default PageStore.


I must be walking in in the middle of something I don't "get".  I'm  
looking at this from the overall perspective of CookbookAuthorsUnite  
-- you're looking at it for your own recipe.

The subject line makes this sound rather generic, like the values/ 
arrays being discussed are settings that many cookbook authors would  
be sharing.  So I thought about it from my own point of view, of  
course, which is that of the AuthUserDBase perspective, where  
technically one could grab usernames/authentication methods from  
multiple databases -- even of the same type (mysql, etc.)

You were talking about using a variety of databases, but in the  
definitions I see things like type ("mysql") and "database" and  
"server" but not a specific distinct name of each, and I thought "if  
I wanted to authenticate people against multiple databases, I would  
have to name them".  It's the user-friendly thing to do.

Ok, maybe that's not at all where you're going.  If you're not doing  
anything regarding user authentication, then maybe I'm wrong about this.

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?

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"

AuthUserDBase could have
$AUDuse = 'moodle';

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

Now there's a class instance for that connection named $moodle -- but  
we never need to know that.  Individual recipes can test whether  
another recipe already defined the connection with ADOdb, creating  
less class instances that are redundant.  $Databases['??'] is  
optionally human-readable by the admin, and can be whatever value the  
admin wants in whatever language, or can be a code, numbers, etc.   
For the programmer it's just a matter of typing an extra $ and  
thinking a bit more expansively.

This also helps protect the namespace.  How many people are going to  
define
$db = new NewADOConnection('mysql');
straight out of the documentation -- causing potential namespace  
clashes between recipes....

Are there other concerns?

You said "each database already has a name" but I don't find $db to  
be particularly descriptive or safe.  That's not a "name" but a  
storage container used on the programming end, not the administrator  
end, of a recipe.  "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...

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.  Databases are all about multiple connections.


When writing vbulletin.php I used adodb but the same authentication  
as the AuthUserDBase -- so I copied the variables -- what a waste.  I  
thought there should be a better way to share the same info.  Many  
hosting services only give you one database to connect to.  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?

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

----

Another reason I'm writing is to verify whether you're working on  
database-based authentication.  I'm slated to work, alone or with Ben  
Wilson, on improving AuthUserDBase and incorporating ADOdb, etc.  If  
you're working on it, then I shouldn't.  We don't need more  
confusion, Ben & I discussed eliminating confusion by merging the  
AuthUserDBase and XesAuthUserDBase recipes.  So I wanted to check  
whether or not this is something that is part of your recipe.  I  
doubt it, but it's better that I ask.


Crisses
-- 
I am Jack's supposedly fictitious alter ego.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20061015/f048b066/attachment.html