daniel added a comment.
There is no redirection to maintain. The blob url from the old revision In https://phabricator.wikimedia.org/T107595#2265137, @GWicke wrote: > Makes sense, some of these fields won't change between revisions. Depending on the constraints, it might still make sense to store unchanged content & rely on compression to encode it efficiently, rather than introduce & maintain a redirection. There's no redirection. When a slot is not edited between revisions, the respective rows in the slots table would simply contain the same blob ID. Or to put it differently: when creating a new revision, all (primary) slots are copied to the new revision, except for the ones explicitly changed for the new revision. So if rev 1 has a slot record for slot X that specified the blob url restbase:uri:abc (1,X,restbase:uri:abc), and rev 2 doesn't edit slot X, then rev 2 will have (2,X,restbase:uri:abc). No aliasing, no redirection. Just the same blob data url. > In any case, as long as you ask the backend for content for a specific title / page id, revision & UUID, backends are free to use whatever performs best. As the code is currently designed, the storage backend would never be called for slots that remain the same for the new revision. Why would it? We'd have to load all the data and then send it back to the backend, for nothing. TASK DETAIL https://phabricator.wikimedia.org/T107595 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
