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

[Crisses]

On Oct 15, 2006, at 1:19 PM, marc wrote:

> Crisses said...
>
>> 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?
>
> 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.)

;) Sounds like the voice of a volunteer.

What's phpmailer?  newsletter mailer?

>> 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
> object.
>
>   $dbtype = $db['moodle']->get_dbtype();

Because that's not very much different than:
$dbtype = $Databases['moodle']['type'];

thus doesn't warrant having to make a whole class layer for it.

If you have good reasons sure -- but right now we're taking a big  
step as recipe authors to incorporate ADOdb.  Doing so moves the  
database-using recipes out of the hands of the beginner cookbook  
authors (who can ask for help, and learn, but when you want to  
accomplish something quick and concrete that's often too much to ask!).

>> AuthUserDBase could have
>> $AUDuse = 'moodle';
>>
>> then (if $$AUDuse isn't defined...):
>> $$AUDuse = new NewADOConnection($Databases[$AUDuse]['type']);
>
>   if(!is_object($db['moodle']))
>     $db['moodle'] = new db(blah);

This code assumes we know the name/designation of the database :) my  
example was to point out how we don't need to know....
if(!is_object($$AUDuse))
     $$AUDuse = 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
> sufficient, imo.

I was thinking literally "connection" per the use of "connect" with  
regard to database terms.  Query is something you send along the  
connection.  You can both have many connections and multiple queries  
at the same time.  A transactional database should be able to handle  
that whether it comes from a single browser/server connection or  
multiple.  Is anyone dealing with a non-transactional database?

And yes, I'm hoping we could share the connection.  A database-happy  
installation that's very busy would benefit enormously -- i.e. CMS- 
like PmWiki installs with heavy traffic.

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

If transactions are an issue, we have more to worry about from  
multiple browser sessions than multiple in-PmWiki connections to the  
database -- PmWiki runs procedural, so only one thing is really  
happening at a time.  Mostly.  Sorta.

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

Why, if he can delegate the task to his loyal benevolent followers?   
It's only a problem if we disagree.

So far, no one is disagreeing.

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

And that's the whole point :)

Crisses