Menu
▾
▴
phpwiki-talk
|
From: John S. <jst...@gm...> - 2005-10-03 03:44:35
|
Hi All, <RANT> I hate to be a pain about this, and I know I am limited by an enterprise decision to use Oracle for all SQL backends, but I find the SQL coding and the lack of any real developer documentation a HUGE downside to this wiki. = I decided to implement it at my employer as I am a great advocate of Wiki for all types of collaborative documentation, and it suits the PHP/Oracle SOE here. The basic Wiki runs fine, and people are beginning to use it and take it up. The problem nows becomes, how do we make this stuff available off-line? Well, just dump out to html right? Wrong. Firstly there are errors where th= e FileFinder.php where it sets the locale to C, and no such locale exists. This occurs for a lot of "plugin" pages. Then if you are are able to get around that one, there is the small problem really bad SQL programming. I mean "WHERE NULL =3D NULL" and "WHERE 1" which causes Oracle to barf. Prett= y bad programming style when these are used to simply let a lazy programmer append " AND something=3D$somvariable" to a conditional clause, rather than= do some testing of variables and processing them accordingly. And if you are going to do it the lazy way, shouldn't you be doing it in a non SQL implementation specific way? Come on! And searching throuth the code, there seems to be ways to include a list of "excluded pages" but since the coding documentation is basically non-existent this is impossible to fathom. And the lack of documentation explaining an easy way to do it would also be helpful. I mean, isn't this really what wiki is about? Oracle did not work out of the box, and I posted my changes on the phpWiki Wiki. Have these been included in the latest releases and patches? No. Is there any easy way to find out how to contribute to this project? Well, I must be blind 'cause I haven't found much detail on that either. So what happens if you guys release patches? I have to trawl through the code each time and make the same changes to make my oracle implementation work. A rea= l pain for me, but if I want a Wiki at work (and god knows we need one) this is what I have to do. Such an overhead will ensure that Wiki will die here. I am more than willing to contribute to the development of the Oracle part of the wiki. We have resources to run testing here. But I need a wiki that will work and will be well maintained, with cross backend code and non-lazy programming and documentation, particularly in the code. This lack is probably limiting the development, debugging and maintainability of this project and it should be rectified. </RANT> Regards John |
|
From: Reini U. <rei...@gm...> - 2005-10-03 07:05:11
|
On 10/3/05, John Stevens <jst...@gm...> wrote:
> <RANT>
I like rants. Thanks!
> I hate to be a pain about this, and I know I am limited by an enterprise
> decision to use Oracle for all SQL backends, but I find the SQL coding an=
d
> the lack of any real developer documentation a HUGE downside to this wiki=
.
> I decided to implement it at my employer as I am a great advocate of Wiki
> for all types of collaborative documentation, and it suits the PHP/Oracle
> SOE here. The basic Wiki runs fine, and people are beginning to use it a=
nd
> take it up.
>
> The problem nows becomes, how do we make this stuff available off-line?
> Well, just dump out to html right? Wrong. Firstly there are errors wher=
e
> the FileFinder.php where it sets the locale to C, and no such locale exis=
ts.
Interesting. Never heard of a system where setlocale("C") fails.
Please post details to the phpwiki bug tracker. C is the mother of all loca=
les.
> This occurs for a lot of "plugin" pages. Then if you are are able to ge=
t
> around that one, there is the small problem really bad SQL programming. =
I
> mean "WHERE NULL =3D NULL" and "WHERE 1" which causes Oracle to barf. Pr=
etty
> bad programming style when these are used to simply let a lazy programmer
> append " AND something=3D$somvariable" to a conditional clause, rather th=
an do
> some testing of variables and processing them accordingly. And if you ar=
e
> going to do it the lazy way, shouldn't you be doing it in a non SQL
> implementation specific way? Come on!
If you dig into the sources, you will see that those TRUE statements (also =
1=3D1)
come from the search library, which is a pretty good library IMHO.
We can easily set another SQL TRUE statement for this branch, and we
haven't wrote a branch optimizer yet.
Recommendations welcome.
I'm just improving the postgresql interface, and oracle is not very far awa=
y.
(foreign keys and text search improvements)
> And searching throuth the code, there seems to be ways to include a list=
of
> "excluded pages" but since the coding documentation is basically
> non-existent this is impossible to fathom. And the lack of documentation
> explaining an easy way to do it would also be helpful. I mean, isn't thi=
s
> really what wiki is about?
You miss coding documentation? I cannot agree.
I would agree that you miss updated user documentation for such features.
> Oracle did not work out of the box, and I posted my changes on the phpWi=
ki
> Wiki. Have these been included in the latest releases and patches? No. =
Is
> there any easy way to find out how to contribute to this project?
I'll look these up. Thanks for your patches.
For the future:
Patches go to patches, bugs to bugs, feature enhancements to RFE.
("Requested Feature Enhancements")
All at the sf.net projects page.
> Well, I must be blind 'cause I haven't found much detail on that either. =
So what
> happens if you guys release patches? I have to trawl through the code ea=
ch
> time and make the same changes to make my oracle implementation work. A
> real pain for me, but if I want a Wiki at work (and god knows we need one=
)
> this is what I have to do. Such an overhead will ensure that Wiki will d=
ie
> here.
$ cd my-oracle-wiki
$ patch -N -b -p1 < ../official-wiki.patch
$ find -name \*.rej | xargs emacs
looks not much of an overhead to me.
I have about 5 different wiki's to sync, with various features to test,
and it's very painless.
> I am more than willing to contribute to the development of the Oracle pa=
rt
> of the wiki. We have resources to run testing here. But I need a wiki t=
hat
> will work and will be well maintained, with cross backend code and non-la=
zy
> programming and documentation, particularly in the code. This lack is
> probably limiting the development, debugging and maintainability of this
> project and it should be rectified.
> </RANT>
--
Reini Urban
http://phpwiki.org
|
|
From: John S. <jst...@gm...> - 2005-10-03 23:14:34
|
Hi Reini and All,
On 10/3/05, Reini Urban <rei...@gm...> wrote:
>
>
> I like rants. Thanks!
So do I, they usually provide useful information;)
>
> Interesting. Never heard of a system where setlocale("C") fails.
> Please post details to the phpwiki bug tracker. C is the mother of all
> locales.
I'll send this to the bugtracker later, but for now, here are the details o=
f
the error we see.
Fatal Error: lib/FileFinder.php (In template 'body' < 'htmldump'):191:
Error: locale/C/LC_MESSAGES/phpwiki.php: ????????????
Not exatly a helpful message. It is looking for the file
[wikihome]locale/C/LC_MESSAGES/phpwiki.php. Problem is there is no locale/C
or any subdirectories, either on my machine or in the 1.3.11p1 archive.
If you dig into the sources, you will see that those TRUE statements (also
> 1=3D1)
> come from the search library, which is a pretty good library IMHO.
I must disagree with this assessment. There should be no reason to do a TRU=
E
statement like 1 or 1=3D1 or NULL=3DNULL in any SQL. It is simply a way of
preformatting a WHERE clause so you can just keep tacking AND condition
statments to it, if there is a reason to. It is lazy programming. You shoul=
d
only create a WHERE clause if there are conditions that you need to limit a
query to. If you dont, then SELECT column1,column2 FROM tablex; is all you
need. Not SELECT column1,column2 FROM tablex WHERE 1=3D1; That is just lazy
programming.
We can easily set another SQL TRUE statement for this branch, and we
> haven't wrote a branch optimizer yet.
> Recommendations welcome.
> I'm just improving the postgresql interface, and oracle is not very far
> away.
> (foreign keys and text search improvements)
While I cannot work out where I can contribute to this, I am looking forwar=
d
to a much better Oracle implementation and will be keen to try it out.
You miss coding documentation? I cannot agree.
I am willing to be proven wrong ;) Can you point me in a direction to find
it? Thanks. Comments in the code are insufficient for someone not intimatel=
y
invovled in the development to get a rapid handle on how it all hangs
together.
I would agree that you miss updated user documentation for such features.
Is there are place I can find this also?
I'll look these up. Thanks for your patches.
Find them on the JohnStevens page. http://www.phpwiki.org/JohnStevens
For the future:
> Patches go to patches, bugs to bugs, feature enhancements to RFE.
> ("Requested Feature Enhancements")
> All at the sf.net <http://sf.net> projects page.
Thanks. Will remember that next time.;)
$ cd my-oracle-wiki
> $ patch -N -b -p1 < ../official-wiki.patch
> $ find -name \*.rej | xargs emacs
>
> looks not much of an overhead to me.
> I have about 5 different wiki's to sync, with various features to test,
> and it's very painless.
Painless if I haven't made a lot of changes to your source. I need to remak=
e
my changes by hand once I have your code patched or have an updated release=
.
If my changes are part of the release..........
Anyway, thanks for the response and guidance. Hope we can work on this
together. A great project that can be improved just a little. Any advice on
how to make the dump to XHTML exclude unwanted pages etc?
Regards
|
|
From: Reini U. <rei...@gm...> - 2005-10-10 08:24:32
|
On 10/4/05, John Stevens <jst...@gm...> wrote: > > If you dig into the sources, you will see that those TRUE statements (a= lso > 1=3D1) > > come from the search library, which is a pretty good library IMHO. > > I must disagree with this assessment. There should be no reason to do a > TRUE statement like 1 or 1=3D1 or NULL=3DNULL in any SQL. It is simply a= way of > preformatting a WHERE clause so you can just keep tacking AND condition > statments to it, if there is a reason to. It is lazy programming. You > should only create a WHERE clause if there are conditions that you need t= o > limit a query to. If you dont, then SELECT column1,column2 FROM tablex; = is > all you need. Not SELECT column1,column2 FROM tablex WHERE 1=3D1; That = is > just lazy programming. I've looked this up. WHERE NULL=3DNULL comes from Pear::DB/oci8.php modifyLimitQuery, not from our search library, so please continue your rant at the pear list :) It's quite tricky. Thanks for your WantedPages fix. (p.id =3D linked.linkfrom) We got this wrong for a long time now. I moved ISNULL to PearDB_mysql and fixed the AS issue in FROM. > > We can easily set another SQL TRUE statement for this branch, and we > > haven't wrote a branch optimizer yet. > > Recommendations welcome. > > I'm just improving the postgresql interface, and oracle is not very far > away. > > (foreign keys and text search improvements) > > While I cannot work out where I can contribute to this, I am looking > forward to a much better Oracle implementation and will be keen to try it > out. Most of the other fixes were based on older releases and already fixed a while ago. I just added DBAUTH_PREF_INSERT as suggested and as default. -- Reini Urban http://phpwiki.org/ |
|
From: Reini U. <rei...@gm...> - 2005-10-04 06:37:15
|
On 10/4/05, John Stevens <jst...@gm...> wrote:
> On 10/3/05, Reini Urban <rei...@gm...> wrote:
> > Interesting. Never heard of a system where setlocale("C") fails.
> > Please post details to the phpwiki bug tracker. C is the mother of all
> locales.
>
> I'll send this to the bugtracker later, but for now, here are the detail=
s
> of the error we see.
> Fatal Error: lib/FileFinder.php (In template 'body' < 'htmldump'):191:
> Error: locale/C/LC_MESSAGES/phpwiki.php: ????????????
>
> Not exatly a helpful message. It is looking for the file
> [wikihome]locale/C/LC_MESSAGES/phpwiki.php. Problem is
> there is no locale/C or any subdirectories, either on my machine or in th=
e
> 1.3.11p1 archive.
This is a useful error message. Thanks. I'll fix it ASAP.
> > If you dig into the sources, you will see that those TRUE statements (a=
lso
> 1=3D1)
> > come from the search library, which is a pretty good library IMHO.
>
> I must disagree with this assessment. There should be no reason to do a
> TRUE statement like 1 or 1=3D1 or NULL=3DNULL in any SQL. It is simply a=
way of
> preformatting a WHERE clause so you can just keep tacking AND condition
> statments to it, if there is a reason to. It is lazy programming. You
> should only create a WHERE clause if there are conditions that you need t=
o
> limit a query to. If you dont, then SELECT column1,column2 FROM tablex; =
is
> all you need. Not SELECT column1,column2 FROM tablex WHERE 1=3D1;
> That is just lazy programming.
Well, I wouldn't disqualifying the search library as lazy, more as
overkill. Unfortunately we need such a beast.
It's a search string string expression parser and compiler. It
compiles to either pcre expressions or SQL statements. On the SQL side
dependend on the backend supported syntax.
In style similar to a perl (not-yet existing) SQL::Search library
which would use the great SQL::Abstract.
The problem you have is with the optimizer step, which folds TRUE to
1=3D1 and doesn't eliminate unnecessary statements.
We thought that this is not necessary since the SQL parser eliminates
these in his side. I didn't think of oracle, since I couldn't test it
(yet).
("Premature optimization is evil")
BTW: Now I do have oracle, but didn't set it up yet.
> > You miss coding documentation? I cannot agree.
>
> I am willing to be proven wrong ;) Can you point me in a direction to f=
ind
> it? Thanks. Comments in the code are insufficient for someone not
> intimately invovled in the development to get a rapid handle on how it al=
l
> hangs together.
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.
> > I would agree that you miss updated user documentation for such feature=
s.
>
> Is there are place I can find this also?
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 pag=
es.
--
Reini Urban
|
|
From: John S. <jst...@gm...> - 2005-10-04 23:54:13
|
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 |
|
From: Reini U. <rei...@gm...> - 2005-10-11 06:17:23
|
Am just trashing my system with the overall testsuite and noticed some minor glitches with default locale detection. It works ok, but breaks the testsuite. I'll release 1.3.12 as soon as some important goals are met. From the 1.3.12 TODO list: * DB: ANSI SQL, foreign key support, simplify methods, full transaction tests (to be tested) * pcre textsearch with multiple words: order-independency * SQL textsearch with multiple words: AND (the two new failing unit tests) * fix textsearch optimize with "word -word -word" * finish moacdropdown integration (for now xmlrpc, widgets later) * the new Mailer class (50%) + better From (to be tested) * finish ModeratedPages (mailer) * finish the new Toolbar buttons (memory =3D> xmlrpc) * re-enable pagedata_cache->next iterator (?, mem test) * investigate setupwiki and dumphtml memory consumption (reset cache and rcs_id in templates?) Maybe: * HtmlParser and importer plugins (word, excel, html, interwiki) * TrackBack, Blog, On 10/11/05, John Stevens <jst...@gm...> wrote: > > I've looked this up. > > > > WHERE NULL=3DNULL comes from Pear::DB/oci8.php modifyLimitQuery, not > > from our search library, so please continue your rant at the pear list > > :) > > Ah, OK. NULL=3DNULL is not something that will break code, but it shoul= d > still be fixed. I probably won't bother ranting over there. I have bett= er > things to be doing ;). But if I am so inclined.......... > > > > I just added DBAUTH_PREF_INSERT as suggested and as default. > > And the peice of code in ./lib/WikiUser/PearDb.php that uses it I hope ;= ) > Pretty useless without it. > Thanks Reini. Keep up the good work. When will we see a new release or > patch release with these changes? > Regards -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X