[dokuwiki] TablesToLock option (was: [PATCH] MySQL canDo() patch)

Hi again :-)

> A word to the option 'TablesToLock'. People blamed me that the
> mysql backend is not save because it doesn't use transactions.
> They don't understand that the backend have to work with mysql
> 3.23 too and that transactions are first usable in mysql 4.0.
> Therefore I do my best to protect database requests with table
> locks. These locks are not perfect but give you the best chance
> to keep you data intact and dokuwiki running. 

I perfectly understand that and think the locking is a good idea in
general.

BTW. did those people contact you personally? That would be great -
usually the bother me first ;-)

> You might be right that READ locks are not so important but they
> are the one and only security feature that protects your database
> inegrity and I would really ask you: Would you accept the risk of
> dokuwiki program failures and data corruption for the short term
> benefit of letting the 'TablesToLock' option undefined? 

There can not be done any harm to the database when no write
modifications are done. Reading without a lock could only result in
reading partly invalid data (eg. the old email address instead of the
just changed one). Nothing I would care for in DokuWiki.

What I try to do here is to simplify authenticating against an external
database. You certainly remember that it wasn't possible to modify
or create users through DokuWiki in the very first version of the MySQL
backend. This was enough for some people - they don't want DokuWiki
touching their database (this includes locking). All they want is simple
reading.

So what I suggest is to make the TablesToLock config string optional
when only readonly strings are defined. As soon as there is any
modification statement defined, TablesToLock should be mandantory.

Andi

Other related posts: