[pmwiki-users] most user-friendly method of database configuration
crisses at kinhost.org
Sun Oct 15 12:07:30 CDT 2006
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
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
> 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
> (:dataquery fields=username,password from=user_table fmt=list:)
Eep -- I have no plans for user authentication to end up in wiki
> 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.
More information about the pmwiki-users