[dokuwiki] The database question: a new spin
- From: "Joe Lapp" <joe.lapp@xxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Tue, 13 Sep 2005 22:42:54 -0500 (CDT)
One of the main reasons I switched to DokuWiki (from a blog/CMS) was that it
wasn't DB-based. It was a nightmare trying to repurpose all my valuable
content once it was scattered across some obscure schema, and besides, the text
editor is still my favorite editor, and I always want the option of using it.
But now that I'm using DokuWiki I'm getting a better feel for the limitations
of not using a DB and also for where a DB belongs and where it doesn't. I'm
pleasantly surprised at how few limitations there are. It appears that the
limitations are primarily in performance, but that sometimes poor performance
prohibits features that would otherwise be no-brainers when using a DB.
==== The Role of the DB ====
So I now believe that the DB ought to be an optional feature for enhancing
performance, but not the original source of configuration or content. A DB
ought to behave like a cache directory, such that it's possible to scratch the
entire database and have the server subsequently auto-generate the DB on the
fly from original file system content.
I think this vision is in line with the reason for not using a DB, as stated in
the DokuWiki FAQ:
"It would be possible, but there was a reason for not doing it. DokuWiki was
designed to hold documentation of all kinds. So what do you do when your
database or your webserver is down and the documentation to bring it up again
is only accessible through this webserver or database? Yikes! So DokuWiki
stores all this vital information as plain text which is always readable, even
if you only have some tape backups left of your beloved Server :-)."
==== Implementation ====
I'd accomplish this by doing good OO design and hiding indexing/lookup
mechanisms behind abstract interfaces. The standard DokuWiki implementations
of these interfaces would in some cases simply pull data from original source
files and in some cases pull data from custom flat file indexes. However,
those caring about performance (such as myself) could create alternative
implementations of those interfaces that transparently utilize a database and
thus provide much better performance.
There may need to be some decisions about DokuWiki behavior that depends on
available performance, so we may need to create something like a performance
configuration variable, establishing the performance level and toggling certain
performance-sensitive features on and off.
Just some thoughts to stew on...
~joe
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
