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

[Pico]

Crisses wrote:
> 
> 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.
> 

Lets not set up a false conflict here.  You and the Bens (S and W) are 
each doing wonderful things for PmWiki and have each demonstrated a 
commitment to contributing to the community.  In this, and other posts, 
each of you often start from the perspective of the projects that you 
are engaged in.  That fact that your project involves an effort to unify 
two security recipes does not change the fact that you and Ben S are 
each thinking about this from your own point of view.  Of course.  So 
what.  What matters is whether you are each open enough to recognize and 
pursue opportunities for cookbook authors to unite.  The answer is yes, 
for each of you, judging by your respective posts to Caveman, for one.

> 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, 

Yes, 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.  But you didn't really make your case for naming until this post, 
and so you should understand that the prior exchange may have lacked 
some important context and substance.
> 
> 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.
> 

Why would you be wrong (or right) based on whether Ben S is thinking 
about user authentication.  If you are right, you are right.

> 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.  

Yes.  I completely agree with you.

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?

I would think that the biggest potential problem to be addressed is 
whether distinctions should be drawn between access db for content and 
for security.  If you provide unified connection code that fails to 
distinguish between content used for publishing and content used for 
security, then won't there be a danger that security information will be 
inadvertently published?  The issue can arise with two separate dbs, and 
  can be complicated if the same db contains tables to store content and 
security data.

So, in the end, the issue may not really be about providing names for 
connections so that they can be shared, but in providing a mechanism to 
distinguish db data intended for publication from data intended for 
security.

As with most of my posts in this area, please keep in mind the running 
disclosure that I don't know what I am talking about, but I see what I 
see (like the fool who says the sun is rising, I may just be right).

> 
> 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).

Yes, please.

> 
> ----
> 
> 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.
> 
> 

Ben can answer that, I can't.  But my impression is that we (as a 
community) will be best served if recipe authors work together to 
provide solutions that can be layered to work together, and that there 
is no need to "re-invent the wheel."


Thanks for all your help and insights.

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

Regards to Jack.

Pico

-- 

         __  /
        /   /
       /___/ _/  ___/  __  /
      /      /  /     /   /
    _/     _/  ____/ ____/

 >>>===pmwiki at ben-amotz.com===>