| Index: trunk/phase3/maintenance/tables.sql |
| — | — | @@ -490,29 +490,53 @@ |
| 491 | 491 | -- all such pages are in namespace 14 (NS_CATEGORY). |
| 492 | 492 | cl_to varchar(255) binary NOT NULL default '', |
| 493 | 493 | |
| 494 | | - -- The title of the linking page, or an optional override |
| 495 | | - -- to determine sort order. Sorting is by binary order, which |
| 496 | | - -- isn't always ideal, but collations seem to be an exciting |
| 497 | | - -- and dangerous new world in MySQL... The sortkey is updated |
| 498 | | - -- if no override exists and cl_from is renamed. |
| | 494 | + -- A binary string obtained by applying a sortkey generation algorithm |
| | 495 | + -- (Language::convertToSortkey()) to page_title, or cl_sortkey_prefix . "\0" |
| | 496 | + -- . page_title if cl_sortkey_prefix is nonempty. |
| 499 | 497 | -- |
| 500 | | - -- Truncate so that the cl_sortkey key fits in 1000 bytes |
| 501 | | - -- (MyISAM 5 with server_character_set=utf8) |
| | 498 | + -- Truncate so that the cl_sortkey key fits in 1000 bytes (MyISAM 5 with |
| | 499 | + -- server_character_set=utf8). FIXME: this truncation probably makes no |
| | 500 | + -- sense anymore; we should be using varbinary for this, utf8 will break |
| | 501 | + -- everything. |
| 502 | 502 | cl_sortkey varchar(70) binary NOT NULL default '', |
| | 503 | + |
| | 504 | + -- A prefix for the raw sortkey manually specified by the user, either via |
| | 505 | + -- [[Category:Foo|prefix]] or {{defaultsort:prefix}}. If nonempty, it's |
| | 506 | + -- concatenated with a null followed by the page title before the sortkey |
| | 507 | + -- conversion algorithm is run. We store this so that we can update |
| | 508 | + -- collations without reparsing all pages. |
| | 509 | + cl_sortkey_prefix varchar(255) binary NOT NULL default '', |
| 503 | 510 | |
| 504 | 511 | -- This isn't really used at present. Provided for an optional |
| 505 | 512 | -- sorting method by approximate addition time. |
| 506 | | - cl_timestamp timestamp NOT NULL |
| | 513 | + cl_timestamp timestamp NOT NULL, |
| | 514 | + |
| | 515 | + -- Stores $wgCollationVersion at the time cl_sortkey was generated. This can |
| | 516 | + -- be used to install new collation versions, tracking which rows are not yet |
| | 517 | + -- updated. 0 means no collation, this is a legacy row that needs to be |
| | 518 | + -- updated by updateCollation.php. In the future, it might be possible to |
| | 519 | + -- specify different collations per category. |
| | 520 | + cl_collation tinyint NOT NULL default 0, |
| | 521 | + |
| | 522 | + -- Stores whether cl_from is a category, file, or other page, so we can |
| | 523 | + -- paginate the three categories separately. This never has to be updated |
| | 524 | + -- after the page is created, since none of these page types can be moved to |
| | 525 | + -- any other. |
| | 526 | + cl_type ENUM('page', 'subcat', 'file') NOT NULL default 'page' |
| 507 | 527 | ) /*$wgDBTableOptions*/; |
| 508 | 528 | |
| 509 | 529 | CREATE UNIQUE INDEX /*i*/cl_from ON /*_*/categorylinks (cl_from,cl_to); |
| 510 | 530 | |
| 511 | | -CREATE INDEX /*i*/cl_sortkey ON /*_*/categorylinks (cl_to,cl_sortkey,cl_from); |
| | 531 | +-- We always sort within a given category, and within a given type. FIXME: |
| | 532 | +-- Formerly this index didn't cover cl_type (since that didn't exist), so old |
| | 533 | +-- callers won't be using an index: fix this? |
| | 534 | +CREATE INDEX /*i*/cl_sortkey ON /*_*/categorylinks (cl_to,cl_type,cl_sortkey,cl_from); |
| 512 | 535 | |
| 513 | 536 | -- Not really used? |
| 514 | 537 | CREATE INDEX /*i*/cl_timestamp ON /*_*/categorylinks (cl_to,cl_timestamp); |
| 515 | 538 | |
| | 539 | +-- For finding rows with outdated collation |
| | 540 | +CREATE INDEX /*i*/cl_collation ON /*_*/categorylinks (cl_collation); |
| 516 | 541 | |
| 517 | 542 | -- |
| 518 | 543 | -- Track all existing categories. Something is a category if 1) it has an en- |