This isn't used anywhere. Theoretical code using would gracefully
fallback to 'md4' given extra params are ignored by PHP.
In terms of future roadmap, I do expect that this algo may have to
change one day based on information that might come to light around
whether MD4 will remain sufficiently fast and/or sufficiently unique.
However, I do not expect that to be so significant in difference that
we'd have to remain some callers on MD4 whilst others adopt something
else. It seems fine that, if that time comes, to simply switch it
and thus consider the algo an implementation detail.
Bug: T32956
Change-Id: Ia9e1366b802ac18f439ce0c802189ede0a2c63f0
Decouple from MW-specific ObjectCache class and stateful servie
wiring that lies behind it, which currently make it impossible
to test FileModule in a pure unit test. This is also in prep for
resourceloader being standalone.
Remove fallback to HashBagOStuff, previously used if a server
doesn't have php-apcu. This fallback didn't seem useful as it
would only retain fairly large amounts if data in memory, that
is actually not re-used as we generally don't hash the same file
multiple times, or at least not in significant quantities that it
outweighs the out-of-the-box risk in memory use for large RL
startup responses where many 10,000s of files get hashed.
Bug: T32956
Change-Id: I809951d34feb2dbd01b7ae0f4bd98dac7c3f6fe2
This allows the backend to do whatever it can to ensure atomicity, and
is also easier to read, since the intent is obvious.
Change-Id: Ibbfecd92a2c6d9a5997ca37ea101e068bd1e8202
Instead of hashing each file separately, hash them in a batch.
Previous research on this area of code has identified the suppressing
and restoring of warnings to have a measurable cost, which is why
this was optimised in 3621ad0f82. However, we never really made
use if it (aisde from the 2:1 change in that commit itself), because
we always call it with a single item, turn it into an array, do the
hash and then merge it again.
Instead, we now let it handle a single module's set of files all
at once. Given that this no longer exposes an array of hashes,
also update the (private) signature of getFileHashes to reflect this.
This means all file modules will have their version bumped during the
next MediaWiki release. In general this happens for most releases
and weekly branches already (due to localisation update, general
maintenance, linting changes, and other internal changes). But,
noting here for future reference as this might not be obvious from
the diff.
Change-Id: I4e141a0f5a5c1c1972e2ba33d4b7be6e64ed6ab6
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
Change-Id: I994d11e05f202b880390723e148d79c72cca29f0
Saves a small trip through ObjectCache::getLocalClusterInstance(),
call_user_func_array, and func_get_args.
Change-Id: If5d2170accaecb6cc8c0520ab9de9241b42a4727
Make sure that PHP warnings are suppressed and restored once per invocation of
FileContentsHasher::getFileContentsHash(), rather than once or twice per file.
Change-Id: I814093f226d62e5e479411d0c3a7bbbe4998255a
- Removed space after cast
- Removed spaces in array index
- Removed double spaces
- Added spaces around string concat
- Fixed mixed tabs and spaces at begin of line
Change-Id: I38e849723f055d2d4c05cba72f5c245a28e8d5da
The class only contains two dependencies upon MediaWiki (ObjectCache &
wfGlobalCacheKey) which are suitable for inclusion in the utils
directory.
Change-Id: I85b4c763be2670c40f26d93e75cedcb68eaa7987
2015-09-24 18:27:28 -07:00
Renamed from includes/FileContentsHasher.php (Browse further)
