phpwiki-talk

[Phpwiki-talk] Pear DB suggestions

[Tomas V.V.C. <co...@id...>]

Hi,

I was by casuality searching for info about what this Wiki idea is and
reached PhpWiki. What was my surprise seeing that it uses PEAR DB and
seeing also some hot discussions about the db abstraction libs. I'm one
of the authors of PEAR DB and couldn't resist to read and take a look at
the code.

Some impressions/ideas:

1) PEAR DB sucks or not :-). PEAR DB is focused in usability and speed
of coding (with unique features like bulk fetching, error handling,
placeholders, easy API, etc). I have to agree with you in some things
I've read like: outdated versions that comes with the PHP distribs,
slower that ADODB or the lack of documentation. All this three points
are changing now with the PEAR web, the DB version 3 and the PEAR manual
(all of them in final tests state). I'm not a marketing guy, I'm just
throwing here my own opinion.

2) About Wiki. I'm looking for an easy solution to one customer and that
seems to fit very well on his needs (no html knowledge, no ftp
abilities, you know.. a user). My only concern is about security and
customization: is there some method to allow only certain users to
add/edit contents? It is easy to change the appereance of the pages
(templates, skins)?

3) About the PEAR DB Wiki driver:

* I see that you are "fighting" with old DB distributions bugs, why you
not: a) ship with your package a recent version of the lib, b) tell the
users to update their PEAR installation (a new lazy way for updating
PEAR on the way is: lynx -source http://pear.php.net/~cox/go-pear| sh).

* Use sequences in _get_pageid() instead of MAX() to avoid race
conditions

* Use $dbh->limitQuery($sql, $from, $offset) in most_popular(),
most_recent() instead of native LIMIT query to easy the migration for
other backends.

* _pear_error_message(). I see that you are removing the password from
the DSN. JFYI The DSN is only exposed in the debugInfo when an error
occurs during the connection. Btw IMHO is not really a good idea to show
to the "users" any part of the DSN (well, even any info comming from
$error->getDebugInfo(), well any non user related problem).

* About the quoting problem. I still see some question and dubts, but I
don't see there the PEAR DB error mentioned in
PhpDatabaseAccessLibraries :-?

* _pear_notice_filter(). Could someone tell me what errors and if they
still persist?

* next(). Good to see that the people need the "autofree" feature, one
more reason to add it :-)

* why you don't drop a mail to pea...@li... when find a bug or
have some problem? :-)

Sorry for this long post if it is out of place.

Regards,

Tomas V.V.Cox

PS.- Please CC me as i'm not suscribed to this list

Re: [Phpwiki-talk] Pear DB suggestions

[Jeff D. <da...@da...>]

Tomas V.V.Cox said:

Thanks very much for the comments!

Here's the quick answers to your questions (at least from
my (one developer) viewpoint).

> .... My only concern is about security and
> customization: is there some method to allow only certain users to
> add/edit contents?

Not yet.  (Other than you could "lock" any/all pages, then only
the administrative user can edit them.)  Currently there's only
support for one authenticated user (the administrator.).

We're moving in the direction of having real authenticated users,
ACL's, etc... but remember the history of Wiki --- the main point is
openness.  Wiki was never meant to be a content management system,
(though some people successfully use it as one.)

> It is easy to change the appereance of the pages
> (templates, skins)?

On a per-wiki basis, yes (more or less).  PhpWiki now has theme
support.  On a per-page basis: no --- there are no hooks for that.

> 3) About the PEAR DB Wiki driver:
>
> * I see that you are "fighting" with old DB distributions bugs, why you
> not: a) ship with your package a recent version of the lib,

We do that now (we didn't initially).  (The selling point which hooked
on on Pear DB in the first place was that it was shipping with PHP.)


> * Use sequences in _get_pageid() instead of MAX() to avoid race
> conditions

I didn't know Pear had sequence support --- I will look into it.
(Note that currently, we lock the tables to avoid the race
condition.)  (It only gets hit when a new page is created, so I
doubt it's a speed bottleneck.)

> * Use $dbh->limitQuery($sql, $from, $offset) in most_popular(),
> most_recent() instead of native LIMIT query to easy the migration for
> other backends.

Again: didn't know limitQuery existed.  Will look into it.
Are some of these more recent features of Pear DB?  Most of the
PhpWiki code is based on whatever version of Pear shipped with
Php 4.0.4pl1.

> * _pear_error_message(). I see that you are removing the password from
> the DSN. JFYI The DSN is only exposed in the debugInfo when an error
> occurs during the connection.

That's right.

> Btw IMHO is not really a good idea to
> show to the "users" any part of the DSN (well, even any info comming
> from $error->getDebugInfo(), well any non user related problem).

There's a fairly fine line between our users and our "admins".
Often people have trouble installing PhpWiki and getting it to work.
Often these people have little knowledge or experience with PHP or
of SQL, so we often get "Halp! It doesn't work!" messages.  The more
debugging information we can dump upon errors, generally the easier
it is to diagnose the problem from afar....

You're right: exposing any part of the DSN is a bit a security flaw,
but as you point out: it only happens when the connection fails...



> * About the quoting problem. I still see some question and dubts, but I
> don't see there the PEAR DB error mentioned in
> PhpDatabaseAccessLibraries :-?

I think the problem went away when we grabbed a recent version of
the Pear DB code from CVS.  There are no bugs which I am aware
of in the version we're now shipping.

> * _pear_notice_filter(). Could someone tell me what errors and if they
> still persist?

IIRC: this was a problem with the Pear code which shipped with PHP 4.0.6.
There were some (My)SQL commands ("LOCK" and "UNLOCK") which don't
return results --- yet the DB code expected them to (problem in
DB::isManip()).  Thus bogus errors would be raised.  Our _is_false_error()
code detects that bogus error.  In the process of raising the error,
DB_mysql::mysqlRaiseError() calls DB_common::errorCode() with a
$nativecode of zero --- PHP then generated a notice a dereferencing
a non-existent index in DB_mysql::errorcode_map.  _pear_notice_filter
hides those notices.

Again, the current CVS code does not have this problem.
Our _pear_notice_filter() and _is_false_error() are no longer
necessary --- since they're doing no harm, I haven't cleaned
them out yet.

> * why you don't drop a mail to pea...@li... when find a bug
> or have some problem? :-)

The bugs we/I have found have always been fixed in CVS by the time
they are found.  All our/my workarounds were efforts to be able to
live with older (standard == "shipped with PHP") versions of the
Pear code.

> Sorry for this long post if it is out of place.

Not at all!  Thanks very much for your input.  Don't be afraid
to chime in again in the future.

Best Regards,
Jeff Dairiki
<da...@da...>