Re: [Phpwiki-talk] A gripe about SQL coding in phpWiki

[John S. <jst...@gm...>]

Hi Reini and all,

>
> Well, I wouldn't disqualifying the search library as lazy, more as
> overkill.


Firstly, I apologise for (in hindsight) using a derogatory term. I did not
mean any personal slights to anyone involved in the phpwiki development.
However, there is a LOT of SQL in the coding that is in the backends that
uses WHERE 1=3D1/NULL=3DNULL/1/TRUE, and it just shouldn't exist. It usuall=
y
exists because the programmer thinks the can start a string variable with
"WHERE TRUE" and then add to it by appending to it " AND fieldn=3D$variable=
"
without any bounds checking on the variable, or even seeing if there are an=
y
variables that need to be included in a WHERE clause. See the bottom of the
JohnStevens page of the phpwiki. This is Disastrous for an abstraction
layer. People are developing SQL implementation specific SQL lower down tha=
n
the abstraction layer where it should be, but not within a particular
implementation specific module. As I found out, most things work, but other
stuff doesn't and causes problems. I re-iterate, there should NEVER be a
WHERE TRUE clause. There should only ever be a WHERE field=3DTRUE. If an
implementation of SQL requires there always be a WHERE clause, and at a
minimum it must be WHERE TRUE, then it should be a part of that
implementations interface module, NOT part of an abstraction layer.

Unfortunately we need such a beast.


Absoultely! But it should be a true abstraction layer, not reliant on any
backend code or DB implementation specific coding, nor should it generate
any. That should be done totally by the backend modules. They should also b=
e
as cross compliant as possible with only really implementation specific
stuff in them.

The problem you have is with the optimizer step, which folds TRUE to
> 1=3D1 and doesn't eliminate unnecessary statements.


See above. If there are no conditionals the optimiser needs to add to a
WHERE clause, then it shouldn't produce one, unless the backend
implementation requires it (doubtful). Leaving a WHERE TRUE clause on the
end of a SQL is a waste and totally unecessary. The optimiser should remove
all unnecessary SQL code before passing it on the the backend.

BTW: Now I do have oracle, but didn't set it up yet.


We are basically SOE oracle 9i and moving to clustered RAC 10 (I am not the
DBA so I think that is spelled right ;)). We have a full 9i/apache/php dev
environment that I am currently running our internal wiki on. If you need
help with testing, let me know. I can easily set up an instance of any new
wiki for testing.

Others can easily follow. Rapid involvement is not easy, but there are
> lot of people who can write plugins or contribute to various parts,
> based on the code and comments.


Again this wasn't meant as a personal criticism. I have been in development
and adminstration of operating systems and software for 25+years. Comments
in code should give a clear idea of what is going on. There are some really
well commented modules, and others that are less then well commented, which
often happens in collaborative projects. I have always run by the principle=
,
that whatever I develop, I will have to return to it in 5-10 years cold, so
I better be able to understand what is going on. That way, anyone coming in
cold can do the same. Yes, these days people do not run by the same
principle, but they should. Particularly in Open Source development
projects. Also, a good overview of what you are building and how it all fit=
s
together is the foundation of any engineering project, software or
otherwise. It sure would help anyone wanting to contribute time and effort
to this project get up to speed and ensure that what they develop will work
without upsetting the applecart by creating implementation specific code in
a place where it shouldn't be. ;) It would have saved me some days of
trawling through modules figuring out where exactly problems lie with me
getting Oracle working well. ;))


http://phpwiki.org/ should be the central place, besides the basic
> docs in pgsrc/
> > Any advice on how to make the dump to XHTML exclude unwanted pages etc?
>
> exclude=3D<commasep-pagename-list> is a standard argument for all
> actions and plugins using pagelists.
>
> e.g. ?action=3Ddumphtml&exclude=3DNotThese/*,*Private
> action=3Ddumphtml also accepts pages=3D[] to dump only a set of certain p=
ages.
>
> Thanks for this. I will check these out and try them.

Again, aside form the initial frustrated rant, which was actually meant to
improve an already good open source project, I am very happy with what you
all have accomplished so far. My frustration comes from wanting it to be
better, and wanting to be a part of the solution rather than the problem.

phpwiki is suffering a little from people thinking in isolation, and not
being able to test against all likely or documented configurations prior to
release. I would like to see these areas improved. I am not on a crusade or
attack;) If I have come across that way, I sincerely apologise.

Regards