[14:45:25] <Amir1>	 CREATE TABLE /*_*/file (
[14:45:25] <Amir1>	 file_id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL,
[14:45:25] <Amir1>	 ...
[14:45:25] <Amir1>	   file_latest BIGINT UNSIGNED NOT NULL,
[14:45:25] <Amir1>	 ...)
[14:45:26] <Amir1>	 At the same time:
[14:45:26] <Amir1>	 CREATE TABLE /*_*/filerevision (
[14:45:27] <Amir1>	   fr_id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL,
[14:45:27] <Amir1>	   fr_file BIGINT NOT NULL,
[14:45:28] <Amir1>	 ...)
[14:45:28] <Amir1>	 So you can't insert the row into file until you get the filerevision id, but you can't insert the filerevision row without having the file_id. :chicken: :egg:
[14:45:52] <Amir1>	 I'm going to make file_latest nullable
[14:58:56] <Lucas_WMDE>	 wait wat
[14:58:59] <Lucas_WMDE>	 how is it currently working then
[14:59:20] <Lucas_WMDE>	 does it first insert with 0?
[15:00:11] <Amir1>	 it's not working yet :D I'm building it
[15:00:22] <Amir1>	 we are currently using image table
[15:00:45] <Amir1>	 which doesn't have auto_increment PK at all leading to all sorts of fun
[15:03:00] <Lucas_WMDE>	 ah ok
[15:03:08] <Krinkle>	 Amir1: do we need to do it in a single pass?
[15:03:46] <Lucas_WMDE>	 doesn’t page + revision have the same problem with page_latest / rev_page?
[15:03:49] <Krinkle>	 How do we do this for page/revision? It seems that is bidirectional as well?
[15:03:54] <Lucas_WMDE>	 jinx ^^
[15:04:09] <Krinkle>	 				"comment": "Handy key to revision.rev_id of the current revision. This may be 0 during page creation, but that shouldn't happen outside of a transaction... hopefully.",
[15:04:50] <Krinkle>	 INSERT page, pageId = insertId, INSERT revision, rev_page=$pageId, UPDATE page_latest = $revId.
[15:04:58] <Krinkle>	 I'm not sure I noticed that before
[15:05:51] <Lucas_WMDE>	 I guess https://phabricator.wikimedia.org/T18674 is what happens if those revisions escape confinement^W the transaction
[15:05:56] <Lucas_WMDE>	 (or not. no idea. maybe it’s another cause)
[15:06:00] <Krinkle>	 WikiPage::insertOn(), page_latest = >0. And then, WikiPage::updateRevisionOn()
[15:29:36] <Amir1>	 yeah, we can create recordUpload4() and do that there
[15:34:20] <tgr|away>	 recordUpload_v4_latest_UPDATED()
[15:37:54] <Amir1>	 lol
[15:45:01] <Krinkle>	 Lucas_WMDE: I expect the failure to result in page_latest remaining 0, not rev_page=0. We do `INSERT INTO page,` with page_latest=0, then `INSERT INTO revision`, and then `UPDATE page SET page_latest=$revId`.
[15:45:28] <Krinkle>	 The way that could fail, perhaps 10 years ago, is if this code is executed on the command-line instead of on the web. And thus there is no default transaction around the whole process.
[15:45:42] <Krinkle>	 So some kind of php fatal in the  middle could cause page_latest to dangle with 0.
[15:45:51] <Krinkle>	 Although it seems we might not have any case of that havig happened in the past
[15:46:21] <Krinkle>	 this task is about rev_page=0. That seems more likely a coding bug where perhaps null got casted to zero. Or maybe something with undelete. 
[15:47:53] <Krinkle>	 AFaik we used to not preserve page_id in the archive table. So an undelete would perhaps involve logic changing rev_page after the fact. If that code contained a bug and set them to $undefinedVariable, that'd result in setting 0.