Aneuch initially used, and likely always will use, a flat-file storage mechanism for its pages. However, it may be necessary at some point for an administrator to use a database back-end for his wiki.
It is my intent to develop a plugin to allow Aneuch to use a database as its back-end sometime in the near future. However, I will likely only write a plugin to use MySQL. The purpose of this page is two-fold. Firstly, to document the development of this MySQL plugin, and secondly, to document the internal workings of Aneuch that need to be modified by any plugin that wishes to implement its own database system. As a fair warning, I may ramble a bit on this page, and I may write my thoughts down directly, which would mean there would be direct contradictions within the same sentence. As long as you approach reading this document from that perspective, it should make perfect sense for you.
Aneuch expects certain things of itself when it comes to storing or retreiving pages from its database. The following functions will need to be modified by any plugin that attempts to replace the storage method.
Aneuch calls GetPage to read a page and its associated metadata from the page database. GetPage is expected to return a hash element which includes the contents of the page. They are (as of 0.30):
The table you store your pages in must have these columns in it. Revision is probably good as an integer. Summary and text should be varchar's or maybe just longtext. Ts will likely need to be a bigint. Ip can be a varchar(16) or just char(15). Diff should be longtext, and author can be something like varchar(31) or similar.
[WritePage?] is used to store data to a page. It accepts these arguments, in order:
WritePage will figure out all the rest of the information it needs (like timestamp, diff, ip, revision number). Obviously, if you replace this function, that will be your job to code those things. Feel free to look into the core Aneuch source to see what it does.
Depending on the table layout you choose (see above for details) you will have to code this function to write out the data in that table layout.
StringToFile will have to be replaced, for obvious reasons (you won't be writing to a file!). This one may be a bit more tricky to work into your database, although not really. I suppose if one had a database table with two columns, the first being a varchar(31) or somesuch, call it filename. The second being longtext, call it contents. This would be relatively easy to set up.
Though you may have to add a 3rd column, call it ts or something, and make it a bigint. This will store the timestamp that the "file" was edited, in case if stat() is ever called. Come to think of it, in doing all of this, I'm going to have to write a new function to replace stat, that way the code will remain modular.
FileToString is another one that will need to be replaced, for obvious reasons. Depending on how you set up StringToFile above, you'll have to tailor this sub to match that.