Thijs/wiki.techinc.nl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
wiki.techinc.nl/includes/filerepo
History
Aaron Schulz 3c7f29a6b9 Add small HtmlCacheUpdater service class to normalize purging code (2) 
This is a re-submit of 35da1bbd7c, which was accidentally merged before
CR (and reverted with aa4da3c2e8).

The purge() method handles purging of both file cache and CDN, using
a PRESEND deferred update. This avoids code duplication and missing
file cache purge calls.

Also:
* Migrate HTMLCacheUpdate callers to just directly using HTMLCacheUpdateJob
* Add HtmlFileCacheUpdate class and defer such updates just like with CDN
* Simplify HTMLCacheUpdate constructor parameters
* Remove BacklinkCache::clear() calls which do nothing since the backlink
  query does not actually happen until the job runs

Bug: T230025
Change-Id: Ic1005e70e2c22d5bd1ca36dcdb618108ebe290f3
2020-04-14 03:19:07 +00:00
..
file Add small HtmlCacheUpdater service class to normalize purging code (2) 2020-04-14 03:19:07 +00:00
FileBackendDBRepoWrapper.php Unit tests for FileBackend 2019-10-30 09:35:13 +02:00
FileRepo.php Coding style: Auto-fix MediaWiki.Usage.IsNull.IsNull 2020-01-10 14:17:13 -08:00
ForeignAPIRepo.php Unsuppress more phan issues (part 3) 2019-08-31 16:38:55 +00:00
ForeignDBRepo.php filerepo: clean up File::getRepo() subclass return type comments 2020-03-19 16:40:15 -07:00
ForeignDBViaLBRepo.php filerepo: clean up File::getRepo() subclass return type comments 2020-03-19 16:40:15 -07:00
LocalRepo.php Coding style: Auto-fix MediaWiki.Classes.UnsortedUseStatements.UnsortedUse 2020-01-10 09:32:25 -08:00
NullRepo.php Set method visibility for various constructors 2019-12-03 20:17:30 +01:00
README.md docs: Remove ingroup tag from Markdown files 2019-11-12 16:11:30 -08:00
RepoGroup.php Upgrade phan config to 0.7.1 2019-09-04 08:20:53 +00:00
TempFileRepo.php

README.md

FileRepo Architecture

Some quick notes on the file/repository architecture.

Functionality is, as always, driven by data model.

  • The repository object stores configuration information about a file storage method.

  • The file object is a process-local cache of information about a particular file.

Thus the file object is the primary public entry point for obtaining information about files, since access via the file object can be cached, whereas access via the repository should not be cached.

Functions which can act on any file specified in their parameters typically find their place either in the repository object, where reference to repository-specific configuration is needed, or in static members of File or FileRepo, where no such configuration is needed.

File objects are generated by a factory function from the repository. The repository thus has full control over the behavior of its subsidiary file class, since it can subclass the file class and override functionality at its whim. Thus there is no need for the File subclass to query its parent repository for information about repository-class-dependent behavior -- the file subclass is generally fully aware of the static preferences of its repository. Limited exceptions can be made to this rule to permit sharing of functions, or perhaps even entire classes, between repositories.

These rules alone still do lead to some ambiguity -- it may not be clear whether to implement some functionality in a repository function with a filename parameter, or in the file object itself.

So we introduce the following rule: the file subclass is smarter than the repository subclass. The repository should in general provide a minimal API needed to access the storage backend efficiently.

In particular, note that I have not implemented any database access in LocalRepo.php. LocalRepo provides only file access, and LocalFile provides database access and higher-level functions such as cache management.

Tim Starling, June 2007