During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
With the new schema, undeletion does not create now slot rows.
However, when in read-old mode, we may still have un-migrated
archive rows. When undeletion based on such a row, we do need
to insert a slot row.
This also changes the return value of SlotRecord for
SCHEMA_COMPAT_READ_OLD mode from null to the negative value of
rev_text_id, for consistency. Conceptually, the emulated slots
in SCHEMA_COMPAT_OLD now have a "virtual" content ID, hich is
however distinct from any real content ID that may exist in
the future. Such virtual content IDs are however not assigned
in SCHEMA_COMPAT_WRITE_BOTH mode. In that mode, unmigrated
rows can be detected by calling hasContentId() on the main
slot. Migrated rows will return true here and provide the
id of the associated content row, even in
SCHEMA_COMPAT_READ_OLD mode. This is particularly essential
for undeletion, which needs to maintain the association
between revision and slot rows even in SCHEMA_COMPAT_READ_OLD
mode.
Bug: T174024
Bug: T194015
Bug: T183488
Change-Id: I88ee9809b9752e1e72d635d62e82008315402901
This consolidates tests for getQueryInfo, getArchiveQueryInfo,
getSlotQueryInfo, and similar methods that help application logic
be compatible with different migration stages of different aspects
of the revision storage schema.
Bug: T198561
Change-Id: I8e4ae69d7e00721a0af125afaf9a708f7fe99b0a
Enable inserts to the new MCR db schema in single slot mode only.
TODO:
- RELEASE NOTES
Notes:
- When in MIGRATION_WRITE_NEW or greater, deleting and then
restoring a page will result in different data in the revision table.
For example, if you delete a page that has text_ids present in the
revision table and restore it, the text_ids will be blank after.
- When in MIGRATION_WRITE_BOTH or greater the archive table will
start to ar_content_model entries where previously it would have been
given NULL. This is due to the old content schema having NULL in the db
when the default content model is used, but the new schema will always
have a value, taken from the content_models table
Note: If259b1e1c49ce was squashed into this change.
Bug: T183488
Bug: T174024
Change-Id: Ic2221da30c8f6ac2ba42720fcd568f2d0ed70534
