Oh, and just to stir this up a little more (heh) I've been hearing ideas about shrinking the old table by only storing diffs from the last full edit, that is, for n histories, store 1 complete edit, then store the diffs between that edit and the next n edits. You think we should try doing something like that? Also, I'd like to see the three-revert rule be coded in the software, instead of just being a voluntary rule. Constans, Camille (C.C.) wrote:

OK, I have very little knowledge of database structures, but I feel like weighing in in a kind of "creative discussion" kind of way... Constans, Camille (C.C.) wrote: Well, while that is a disadvantage, I think it may be outweighed by the things such a merger would make possible/easier - there's a bugzilla entry for assigning a lasting ID to latest revision (bug 181) that mentions some of them. It also makes a lot of sense with some of the other changes here. Perhaps the combined table could have a is_latest field, so that you don't have to do any timestamp comparisons, or touch more than one table. Surely, we'll only get 1 row = 1 page if we *do* have a specific table of (page_title, page_id). Otherwise, every revision has a page_title attached to it, hence it's impossible to move [[en:Wikipedia:Village pump]] without more-or-less crashing the server. One thing that occurs to me to wonder, not having seen a full break-down of the new schema, is where is_redirect would end up. I've begun working on a bit of tidying up around the redirect code, and have figured on this as a field that could be used to better effect than it currently (IIRC) is. I guess it would live in the table of revision information (since it changes), and would be another good reason to be able to filter on an is_latest. Like I say, I'm not really hot on DB stuff, but I figure that if we're going to have magic sysop reverts that don't actually touch any text we can't rely on recreating is_redirect by parsing the text. As for how to migrate, I want to refloat an idea I had before, that if the wiki could be put into an 'audit-log' mode (where changes can be made, but aren't entered into the 'real' database), the main db could be set to read only, restructured, and then have the log of changes-that-happened-in-the-meantime applied to it. After that, you just need a short amount of down-time while you switch the databases round. The simplest way of doing that would be to just have two copies of the DB, one running the live site, the other being processed offline. The log could then record all write actions performed on the live site - either in the form of SQL queries used, or in a more abstract format that would be easier to apply to a changed schema. Something along the lines of (if you felt like playing in XML): <edit timestamp"01231231231"><page title="User:IMSoP"><newtext>I 4m teh l33t h4x0r!</newtext></page><user name="V4nd4l" id="666" /></edit> Essentially, a bit like the export/import facility but with the ability to store all kinds of write-action in a way that allows them to be "replayed" by the software into the new database schema. I think it would be very nice not to have to turn the wiki read-only for things that take as long as 1.2 -> 1.3 ended up causing, let alone longer... -- Rowan Collins BSc [IMSoP]