[pmwiki-devel] More database standards
gmane at auxbuss.com
Sun Dec 17 09:37:59 CST 2006
Ben Stallings said...
> 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.
But that will result in every recipe requiring its db and tables to be
uniquely defined. That's a lot of unnecessary extra work when you can
simply define a table once. (By table, I always mean a unique db/table
The effect is that each of these definitions will need to be amended
when using another table, instead of only having to do so in one
The knock on effect is that admins will have to write their own code to
manage db and table changes in their config.php, because the definition
appear more than once. That is something I specifically wished to avoid.
> 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
No, this isn't the case. $DBTables[handle] (e.g. $DBTables[members]) is
simply a PmWiki-wide handle for a table. A table is uniquely identified
by its db and db table name, which is the minimal contents of an
$DBTables entry. This handle can be used anywhere.
Anywhere, in this case, also means within markup, and this is incredibly
useful. For example, I have a generic object display markup for PmWiki.
That means that users can simply say:
(:Show Members='fred blogs':)
(:Show Products='PmWiki t-shirt':)
(:Show Purchases Member='fred blogs':)
Now, wrap that up a bit with a form and an entry field and that's
customer support sorted.
> in which case a
> standard format (array('database'=>dbname, 'table'=>tablename)) is not
This doesn't make sense to me, I'm afraid. Why is it 'not necessary'?
> In fact, if two recipes use the same handle to refer to two different
If the tables are different, then you use different handles. One handle
maps to one table (that is, one unique database/table pair - although
there is nothing to stop someone creating two handles for for the same
> -- because one recipe's "products" are not the same as another's
I'm already doing this in the wild, so it's a good example of why this
mechanism - this very simple mechanism - works in the real world.
In fact, in some cases, we are building multiple result-sets from
multiple "same table" tables on multiple databases and displaying one
set of results.
Where there are multiple products' table, one simply defines a handle
for each one:
'products' => array ( 'database' => $liveDb, 'table' => 'products'),
'products2' => array ( 'database' => $liveDb, 'table' => 'products2'),
'products3' => array ( 'database' => $liveDb, 'table' => 'products3'),
If the recipe writer wants to provide a means for the handle to be
provided as a parameter to a function he may do so. There's no /loss/ of
functionality. Alternatively, the recipe writer can do this via an
additional field in $DBTables array for a table. Indeed, there's nothing
to stop the recipe writer interpreting, say, 'table' as an array and
processing that. e.g.
'products' => array (
'database' => $liveDb,
'table' => array ( 'products', 'producs2', 'products3' ));
> -- using a single variable for both recipes could have unintended
Well, I'd prefer too see you support these 'unintended consequences'
with some specifics, but, as I mentioned above, this isn't how it works.
> 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.
Why do that?
The problem here is that it precludes a generic set of definitions that
is the simplest case, and the most likely to be used by most folk.
Admins can define the required tables once and be done with it.
I have a case where there are only six tables and twenty odd recipes.
$DBTables is 6 lines. It would be 120 lines if each were defined for
Also, you need to keep in mind that classes, and methods within
classes might use a variety of similarly named but physically different
But, in addition, the case you give provides no extra benefit.
> 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.
As I've shown. this is unnecessary, more complex, and creates additional
work to maintain. But, in addition, there's nothing to stop a recipe
writer using their own recipe-specific handles in $DBTables, if they so
> > 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.
Unfortunately, I don't think you have demonstrated these things, but
only asserted them.
While I'm not claiming that what I proposed in the best solution, I put
it out there for discussion.
> 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.
Yes, I have presented quite a lot of code.
> Why should we give you consensus when
> we don't yet understand the benefits of what you're proposing?
Consensus = general agreement. So it's not something you can give, nor
something I could receive.
> > Frankly, for the extra flexibility, I'm at a loss to understand why this
> > is being perceived negatively.
> 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.
I'll sidestep the ad hominem and just leave you to it.
More information about the pmwiki-devel