moodle/moodle
3
0
Fork 0
mirror of https://github.com/moodle/moodle.git synced 2025-08-05 00:46:50 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

MDL-37536 cache: fixed typo

Browse source
This commit is contained in:
Sam Hemelryk 2013-01-16 14:22:58 +13:00
parent 9da506c2a3
commit 759a302454
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
cache/README.md vendored
View file

@ -86,7 +86,7 @@ There are several parts that make up the Cache API.
The loader is central to the whole thing.
It is used by the end developer to get an object that handles caching.
90% of end developers will not need to know or use anything else in the cache API.
In order to get a loader you must use one of two static methods, make or make_with_params.
In order to get a loader you must use one of two static methods, make or make_from_params.
The loader has been kept as simple as possible, interaction is summarised by the cache_loader interface.
Internally there is lots of magic going on. The important parts to know about are:
* There are two ways to get a loader, the first with a definition (discussed below) the second with params. When params are used they are turned into an adhoc definition with default params.
@ -225,4 +225,4 @@ Cache information can be invalidated in two ways.
The first method is designed to be used when you have a single known definition you want to invalidate entries within.
The second method is a lot more intensive for the system. There are defined invalidation events that definitions can "subscribe" to (through the definitions invalidationevents option).
When you invalidate by event the cache API finds all of the definitions that subscribe to the event, it then loads the stores for each of those definitions and purges the keys from each store.
This is obviously a recursive, and therefore, intense process.
This is obviously a recursive, and therefore, intense process.