https://bugzilla.wikimedia.org/show_bug.cgi?id=25312
--- Comment #11 from Brion Vibber <[email protected]> 2011-08-15 19:41:49 UTC --- (In reply to comment #3) > I don't see why #21860 is a blocker - if text is being read, calculating > checksums is cheap enough. > Storing all that in the database isn't free. When creating a stub dump, we haven't read the text yet -- the job of fetching and inserting the text is being deferred to a later process (textDumpPass) which pulls the text either from a previous dump or from the text table / external storage etc. So at that point, only data within the 'page' and 'revision' tables, and anything else that can be very cheaply fetched, is available. A rev_sha1 field that's already been pre-filled out would be usable for creating stub dumps; calculating from text after it's been read would only be usable on the final dumps (or else a second equivalent pass). Using a separate field for this also gives greater confidence that there was not internal data corruption; if the sha1 is generated from the text that's right next to it in the same file, there's no point -- the client could calculate it as easily and reliably as the server could have, and in neither case will it indicate if the data has been corrupted on the backend. (In reply to comment #7) > SHA1 *might* make more sense than MD5, if only because it may help us in a > crazy future where we leverage tools associated with Git or other version > control systems (for example, Mercurial uses SHA1 as well). Not that there's > anything planned, but since the choice of hash is somewhat arbitrary > otherwise, > SHA1 might be slightly preferable. I don't think there'd be much chance at integration here really; git's object references are based on SHA-1 checksums, but of the entire object including a header indicating type ('blob' for files) and size prepended. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
