[dokuwiki] Re: proposals (read if interrested in plugins, db storage and stuff)

On Thu, 2005-07-28 at 10:22 +0200, Harry Fuecks wrote:
> Just butting in as this is something I feel strongly about.
> 
i did not mean to critizise or anything.

> I think Andi has made exactly the right decision to store content in
> flat files. Aside from obvious reasons like it's easy to administer
> flat files from the command line, when it comes to storing content,
> placing documents in a database is like fitting a round peg into a
> square hole.

> There's a short but relevant comment on the Mediawiki mailing lists
> (who do use a database), while there were discussing parser
> performance issues;
> 
> http://mail.wikipedia.org/pipermail/wikitech-l/2005-May/029347.html
> 
> "[...] In hindsight, storing the wikitext in a database was a mistake.
> 
> There's already a wonderful piece of software highly optimized and
> scalable for storing randomly accessed variable-
> sized chunks of text with lots of tools for backup, replication, and so
> on; it's called a file system. [...]"
> 
> From my point of view the only reason why people are asking for MySQL
> is because they're running on a shared host with limited access /
> permissions to the file system and / or no shell access (or perhaps
> not enough experience with Bash). While I can understand the problem
> think it's a bad idea to re-design Dokuwiki just for this purpose and
> I can imagine it being difficult to support both well - either one or
> other will become the "evil twin", never working well and eventually
> suffocating it's brother.
> 
i do not agree, it would be perfectly fine to create a set of functions
which returns and saves data, where one can choose between a PEAR::DB
version or a flatfile version.
> Returning to the issue of dbs in general, the two general benefits of
> a DB is it helps with indexing the data stored - things like searching
> are easier to implement effeciently - and it allows you to define as
> many "properties" as you like for a given "item" (i.e. wiki page) e.g.
> a "Last Modified by" column or a "Number of hits" column. The
> additional properties in particular are more work when using the
> filesystem.
> 
this is also one of the reasons i would like to see database support, i
read that dokuwiki currently is very slow at searching, and i believe a
database storage backend would improve this
> For Dokuwiki I knocked up a couple of pages with thoughts on how to
> tackle this here;
> 
> http://wiki.splitbrain.org/wiki:discussion:indexing
> http://wiki.splitbrain.org/wiki:discussion:metadata
> 
> From my point of view, making the search work fast is "simply" a
> matter of moving the search operation from being "runtime" when the
> user requests it to being "offline" in a cron job which builds indexes
> for fast searching.
now this is certainly not making the software very easy to use, since i
have never seen any webhost giving access to cron, and i myself, have no
idea how to use it.
> 
> I'm pretty sure Andi won't give in anyway but my vote is "No to DBs
> and Dokuwiki!". Better would be putting a page on the wiki listing web
> hosts where Dokuwiki runs well.
well.. as i see it, database wont make anything worse, and as soon as
BOTH options are availiable, i believe it to be an enhancement.
> 
> On 7/27/05, Andreas Gohr <andi@xxxxxxxxxxxxxx> wrote:
> > On Wed, 27 Jul 2005 17:33:06 +0000
> > Matt Pascoe <hornet136@xxxxxxxxx> wrote:
> > 
> > > At this point in time however I prefer the simplicity of the flat
> > > files for storage.  If we can make dokuwiki be configurable to support
> > > either one (or even a mix of both??!?) that would be great.  Just dont
> > > forget about the flat files. :)
> > 
> > Do not worry about that - I will not accept patches which _remove_ flat 
> > file support. Database usage should be completely optional.
> > 
> > Andi
> > 
> > 
> >
-- 
Redeeman <redeeman@xxxxxxxxxxx>

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: