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

[Crisses]

On Oct 15, 2006, at 12:28 PM, Ben Stallings wrote:

> Crisses wrote:
>> 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.
>
> Touche.  I got carried away with the possible ramifications of my  
> recipe and forgot that it wouldn't do everything database-related.   
> At least I know I'm not the first to go down that path. ;-)

No, certainly not.  All is forgiven ;)

>> 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
>
> If you look again at the syntax Pm proposed, you'll see that the  
> database name is the third parameter, though it could just as  
> easily be the first:
>
>     $WikiLibDirs[] = new DataStore(array(
>                       'type' => 'mysql',
>                       'server' => 'db.example.com',
>                       'name' => 'example_database_name',
>                       'user' => 'example_user',
>                       'passwd' => 'example_password'));
>
> But you make a good point that that's not very accessible to other  
> recipes that are not using databases as PageStores.  I'm sold on  
> your rationale for using a single, global $Databases variable for  
> all ADODB-based recipes.

Ah, good.  I think it will save some double-entry for admins, some  
tiny bit of memory & speed during execution (every bit counts  
sometimes!).

And I did miss "name" buried in there.  I was thinking that the name  
would be the key to the array....makes it easy to look up other  
values from a variable.

>> "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 stand corrected.  But (if I may cover my rear by switching  
> arguments) why would you want to have two connections, when you can  
> look at two tables in two queries, or at two tables within a single  
> query, or even the same table twice within a query?
>
> SELECT t1.person_name,t2.friend_name FROM people AS t1, people AS  
> t2 WHERE t1.friend_id = t2.person_id;

The point is that unless we do this as CookbookAuthorsUnite -- we DO  
end up with multiple connections to different tables of the same  
database.  Or potentially do, since I could be authenticating from a  
different database or server than you're writing pagestores to....but  
most of the time I think admins will be using the same database,  
different tables.  In which case why not share the connection...

>> 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.
>
> Thank you.  If I understand AuthUser correctly, and if DataQuery  
> works as I hope it will, all you'll have to do to use a database  
> table for authentication will be to put a line like this in  
> Site.AuthUser:
>
> (:dataquery fields=username,password from=user_table fmt=list:)

Eep -- I have no plans for user authentication to end up in wiki  
markup.... :)

> Assuming the password field is encrypted, and assuming you haven't  
> declared that field off-limits to DataQuery.  But... this list of  
> users would be read-only, because adding users and changing  
> passwords and all that would be a whole other can of worms.  So it  
> would probably be better to stick with your plans for  
> AuthUserDBase.  Unless there's another possibility I'm missing...   
> --Ben S.

Well, one reason I like the stand-alone database auth mechanism is  
that while I own my own server, most people don't, and I wouldn't  
trust my clients' sites and data to their fellow web-hostees.

I also want to allow plug-ins for non-standard authentication  
methods.  vBulletin had their own odd recipe for authentication  
rather than straight MD5 SHA1 php crypt() or mysql password generation.

But I think that end of things is for the admin, not the wikiauthor.

However, I'm all for the ability to access data from the wiki -- it  
can be exceptionally useful for things like protected downloads.

Crisses