It works fine unless you use it
May 17th, 2004
And now, an exciting new chapter in the young life of Cornucopt: nobody can log in and no pages will display.
Last night, I innocently added a bug to the bug list, and the database apparently chose exactly that moment to hit the space limit assigned to it by my ISP. The pages table is now evidently corrupted. I can still pull data out of the changes table, so I was able to rescue some data immediately for the project some friends and I were embarking on (and which probably created all the data that filled the drive).
At least, that’s my best guess as to what happened; I am far from a DBA. But man, that changes table got freakin’ huge.
I had implemented (and have implemented) no “small change” functionality in Cornucopt. In many wikis, you can designate an edit as a “small change” to the page, like a typo correction or a layout tweak, and it will store that change lumped in with the last change, rather than add a new entry in the DB and in Recent Changes, annoying everyone. Good feature, just hadn’t gotten around to it.
It’s relatively simple to add such a “small changes” feature. It needn’t present a security risk of sneaking in a huge change (either by marking it as small, or by doing it slowly).
But is it really what I need? Does it explain how a database table that contained every full version of every page on a small, new wiki got to be 200 megabytes? When the pages in question are about a K at most?
I may have to bite the bullet and limit the number of changes that Cornucopt stores, to something like the last 20. I feel like I’m letting future generations down. For right now, though, I’m investigating all these problems and how other wikis handle them. And, of course, getting my actual work done.
Entry Filed under: Implementation