[pmwiki-devel] More database standards
Ben Stallings
ben at interdependentweb.com
Sat Dec 16 14:36:49 CST 2006
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.
More information about the pmwiki-devel
mailing list