[pmwiki-devel] More database standards

[marc]

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

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

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

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

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 
db/table pair).

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

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

Also, you need to keep in mind that classes, and methods within 
classes might use a variety of similarly named but physically different 
tables. 

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

-- 
Best,
Marc