[pmwiki-devel] More database standards

[Ben Stallings]

Marc wrote:
> Are you suggesting that the standard should be that folk provided the 
> db/table pair in each function call?
> 
> No? I thought not. But I don't understand what you are proposing.

I'm proposing that it be left up to the recipe authors how to write the 
configuration variables that are specific to their recipes.  As I 
understand it, although your $DBTables array provides a standard 
*format* for configuration variables, the variables themselves 
($DBTables[handle]) are specific to each recipe, in which case a 
standard format (array('database'=>dbname, 'table'=>tablename)) is not 
necessary.

In fact, if two recipes use the same handle to refer to two different 
tables -- because one recipe's "products" are not the same as another's 
-- using a single variable for both recipes could have unintended 
consequences.  To avoid that conflict, the recipes would have to use 
handles with recipe-specific prefixes: DHproducts and DQproducts and so 
on... which means they may as well be separate global variables 
$DHproducts and $DQproducts.

So I say, if a recipe is going to use handles at all, it should have its 
own separate configuration variables rather than attempting to share them.

> Well, fine, but we need to agree a 'standard'. Right now, there isn't 
> one, and that's the reason why I raised the issue - to get a consensus. 
> I've spelt out my approach and as yet, no alternative has been offered. 
> Bring it on.

We needed a standard for database *connections*, because we needed to 
prevent redundant connections, and we have such a standard, though 
admittedly it has room for improvement.  Why do we need a standard for 
database *tables*?  You say it reduces the amount of configuration, and 
it may in the recipes you're writing, but I've tried to demonstrate that 
it would have the opposite effect in the recipes I'm writing, and could 
cause problems by limiting the name space available for variables.

So you do not have consensus.  You've gotten me riled up, and it seems 
like Crisses is a little miffed too, and both of us have asked you to 
give us a working script to look at so we can understand what you're 
doing, but you haven't done that.  Why should we give you consensus when 
we don't yet understand the benefits of what you're proposing?

> Frankly, for the extra flexibility, I'm at a loss to understand why this 
> is being perceived negatively. 

Well, just for the sake of analogy, Crisses and I drive on the right 
side of the road.  Most people we know drive on the right side of the 
road and have never done it any other way.  Suppose we propose that the 
Database Standard should require people to drive on the right side of 
the road.  How would that go over in the UK or Australia?

I think our hostility to your suggestion comes from a sense that you're 
trying to add stuff to the standard that has no business there, and far 
from trying to build consensus cooperatively, you're trying to tell us 
the right way to program, and we're not convinced that it is the right 
way.  I hope that helps explain the reaction you're getting.  --Ben S.