MoodleDocs - User contributions [en]

Talk:PHPUnit

2012-10-17T12:44:00Z

Tlevi:

I actually needed to execute

pear install -–alldeps pear.phpunit.de/PHPUnit

and

pear install -–alldeps phpunit/DbUnit

+1 same for me - should be changed in article?
[[User:Tony Levi|Tony Levi]] 20:44, 17 October 2012 (WST)

Caching system (proposed)

2012-01-27T15:51:13Z

Tlevi: /* Keys */

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290].

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle.

Please visit the discussion thread at http://moodle.org/mod/forum/discuss.php?d=189498.

==Basic Requirements==
===Suggestions===
Things the caching system should or must do:
# it should support different backends (static, session, DB, shared memory...).
# any attempt of caching within Moodle should end using it (and not other solutions).
# code should continue working 100% without caching enabled.
# each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
# each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
# each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

===The real thing===
These items have been relaxed or modified somewhat:
* (Re #1) supports multiple backend types, one instance of each type is permitted
** a backend implementation is a 'method', methods implement 'types'
** e.g there is a 'shmem' cache type, which can be backed by either APC or XCache methods
* (Re #2) most caches inside Moodle can use this system, some specialized cases may need to be exempted
* (Re #3) disabling caching is supported, but static cache will remain active in this case for sanity
* (Re #3) elements may disappear at any time from the cache, except static with no size constraint
* (Re #4) Fallback is NOT required, but multiple backends are supported
* (Re #5) callers must provide a unique key for elements, it is their job to form this according to context
** Hashing if needed should be performed inside cache_methods, and collisions must NOT be visible to callers (check full keys too)
* (Re #5) key length is a string with fixed maximum length
** callers could wrap keys+values and store these with using a cache-key that is md5 of the full key
** it should be possible to implement an optional extra layer (like the multicache) which does this for us
* (Re #6) each cache (namespace/tag) has one TTL, NOT per-element

These changes minimise overheads in code and performance while permitting the most common cache uses.

==Outline==
===Caches===
The caching system shall provide access to a series of different caches, referenced by a ''tag''.

Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.

Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Keys===
Keys identify a particular element within a cache. Key collisions between elements are NOT allowed and will overwrite each other.

Keys are limited to 256 characters. If a longer key is required, use the 'md5' option.
Internally, this packs the full key with data and validates the full key after it is retrieved from cache to stop collisions.

TODO: evaluate removing this limit

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init(); // in setup.php
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades and the 'purge all caches' page.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-11-02T05:36:52Z

Tlevi: add discussion link

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290].

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle.

Please visit the discussion thread at http://moodle.org/mod/forum/discuss.php?d=189498.

==Basic Requirements==
===Suggestions===
Things the caching system should or must do:
# it should support different backends (static, session, DB, shared memory...).
# any attempt of caching within Moodle should end using it (and not other solutions).
# code should continue working 100% without caching enabled.
# each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
# each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
# each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

===The real thing===
These items have been relaxed or modified somewhat:
* (Re #1) supports multiple backend types, one instance of each type is permitted
** a backend implementation is a 'method', methods implement 'types'
** e.g there is a 'shmem' cache type, which can be backed by either APC or XCache methods
* (Re #2) most caches inside Moodle can use this system, some specialized cases may need to be exempted
* (Re #3) disabling caching is supported, but static cache will remain active in this case for sanity
* (Re #3) elements may disappear at any time from the cache, except static with no size constraint
* (Re #4) Fallback is NOT required, but multiple backends are supported
* (Re #5) callers must provide a unique key for elements, it is their job to form this according to context
** Hashing if needed should be performed inside cache_methods, and collisions must NOT be visible to callers (check full keys too)
* (Re #5) key length is a string with fixed maximum length
** callers could wrap keys+values and store these with using a cache-key that is md5 of the full key
** it should be possible to implement an optional extra layer (like the multicache) which does this for us
* (Re #6) each cache (namespace/tag) has one TTL, NOT per-element

These changes minimise overheads in code and performance while permitting the most common cache uses.

==Outline==
===Caches===
The caching system shall provide access to a series of different caches, referenced by a ''tag''.

Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.

Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters and collisions between elements are NOT allowed.

If a longer key is required it is use a hash of the full key as the cache key and store the full key with the value.
This allows validation of the full key to stop collisions.

It should be possible to implement an optional extra layer (like the multicache) which does this for us

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init(); // in setup.php
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades and the 'purge all caches' page.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-11-02T05:09:03Z

Tlevi: /* Cache interface */ tweak interface info

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
===Suggestions===
Things the caching system should or must do:
# it should support different backends (static, session, DB, shared memory...).
# any attempt of caching within Moodle should end using it (and not other solutions).
# code should continue working 100% without caching enabled.
# each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
# each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
# each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

===The real thing===
These items have been relaxed or modified somewhat:
* (Re #1) supports multiple backend types, one instance of each type is permitted
** a backend implementation is a 'method', methods implement 'types'
** e.g there is a 'shmem' cache type, which can be backed by either APC or XCache methods
* (Re #2) most caches inside Moodle can use this system, some specialized cases may need to be exempted
* (Re #3) disabling caching is supported, but static cache will remain active in this case for sanity
* (Re #3) elements may disappear at any time from the cache, except static with no size constraint
* (Re #4) Fallback is NOT required, but multiple backends are supported
* (Re #5) callers must provide a unique key for elements, it is their job to form this according to context
** Hashing if needed should be performed inside cache_methods, and collisions must NOT be visible to callers (check full keys too)
* (Re #5) key length is a string with fixed maximum length
** callers could wrap keys+values and store these with using a cache-key that is md5 of the full key
** it should be possible to implement an optional extra layer (like the multicache) which does this for us
* (Re #6) each cache (namespace/tag) has one TTL, NOT per-element

These changes minimise overheads in code and performance while permitting the most common cache uses.

==Outline==
===Caches===
The caching system shall provide access to a series of different caches, referenced by a ''tag''.

Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.

Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters and collisions between elements are NOT allowed.

If a longer key is required it is use a hash of the full key as the cache key and store the full key with the value.
This allows validation of the full key to stop collisions.

It should be possible to implement an optional extra layer (like the multicache) which does this for us

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init(); // in setup.php
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades and the 'purge all caches' page.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-31T01:35:43Z

Tlevi: /* Outline */ remove silly persist info, this is gone now

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
===Suggestions===
Things the caching system should or must do:
# it should support different backends (static, session, DB, shared memory...).
# any attempt of caching within Moodle should end using it (and not other solutions).
# code should continue working 100% without caching enabled.
# each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
# each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
# each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

===The real thing===
These items have been relaxed or modified somewhat:
* (Re #1) supports multiple backend types, one instance of each type is permitted
** a backend implementation is a 'method', methods implement 'types'
** e.g there is a 'shmem' cache type, which can be backed by either APC or XCache methods
* (Re #2) most caches inside Moodle can use this system, some specialized cases may need to be exempted
* (Re #3) disabling caching is supported, but static cache will remain active in this case for sanity
* (Re #3) elements may disappear at any time from the cache, except static with no size constraint
* (Re #4) Fallback is NOT required, but multiple backends are supported
* (Re #5) callers must provide a unique key for elements, it is their job to form this according to context
** Hashing if needed should be performed inside cache_methods, and collisions must NOT be visible to callers (check full keys too)
* (Re #5) key length is a string with fixed maximum length
** callers could wrap keys+values and store these with using a cache-key that is md5 of the full key
** it should be possible to implement an optional extra layer (like the multicache) which does this for us
* (Re #6) each cache (namespace/tag) has one TTL, NOT per-element

These changes minimise overheads in code and performance while permitting the most common cache uses.

==Outline==
===Caches===
The caching system shall provide access to a series of different caches, referenced by a ''tag''.

Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.

Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters and collisions between elements are NOT allowed.

If a longer key is required it is use a hash of the full key as the cache key and store the full key with the value.
This allows validation of the full key to stop collisions.

It should be possible to implement an optional extra layer (like the multicache) which does this for us

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init();
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades etc.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-31T00:27:44Z

Tlevi: /* Keys */ update+clarify

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
===Suggestions===
Things the caching system should or must do:
# it should support different backends (static, session, DB, shared memory...).
# any attempt of caching within Moodle should end using it (and not other solutions).
# code should continue working 100% without caching enabled.
# each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
# each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
# each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

===The real thing===
These items have been relaxed or modified somewhat:
* (Re #1) supports multiple backend types, one instance of each type is permitted
** a backend implementation is a 'method', methods implement 'types'
** e.g there is a 'shmem' cache type, which can be backed by either APC or XCache methods
* (Re #2) most caches inside Moodle can use this system, some specialized cases may need to be exempted
* (Re #3) disabling caching is supported, but static cache will remain active in this case for sanity
* (Re #3) elements may disappear at any time from the cache, except static with no size constraint
* (Re #4) Fallback is NOT required, but multiple backends are supported
* (Re #5) callers must provide a unique key for elements, it is their job to form this according to context
** Hashing if needed should be performed inside cache_methods, and collisions must NOT be visible to callers (check full keys too)
* (Re #5) key length is a string with fixed maximum length
** callers could wrap keys+values and store these with using a cache-key that is md5 of the full key
** it should be possible to implement an optional extra layer (like the multicache) which does this for us
* (Re #6) each cache (namespace/tag) has one TTL, NOT per-element

These changes minimise overheads in code and performance while permitting the most common cache uses.

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters and collisions between elements are NOT allowed.

If a longer key is required it is use a hash of the full key as the cache key and store the full key with the value.
This allows validation of the full key to stop collisions.

It should be possible to implement an optional extra layer (like the multicache) which does this for us

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init();
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades etc.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-31T00:21:18Z

Tlevi: /* Basic Requirements */ headings for separation

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
===Suggestions===
Things the caching system should or must do:
# it should support different backends (static, session, DB, shared memory...).
# any attempt of caching within Moodle should end using it (and not other solutions).
# code should continue working 100% without caching enabled.
# each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
# each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
# each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

===The real thing===
These items have been relaxed or modified somewhat:
* (Re #1) supports multiple backend types, one instance of each type is permitted
** a backend implementation is a 'method', methods implement 'types'
** e.g there is a 'shmem' cache type, which can be backed by either APC or XCache methods
* (Re #2) most caches inside Moodle can use this system, some specialized cases may need to be exempted
* (Re #3) disabling caching is supported, but static cache will remain active in this case for sanity
* (Re #3) elements may disappear at any time from the cache, except static with no size constraint
* (Re #4) Fallback is NOT required, but multiple backends are supported
* (Re #5) callers must provide a unique key for elements, it is their job to form this according to context
** Hashing if needed should be performed inside cache_methods, and collisions must NOT be visible to callers (check full keys too)
* (Re #5) key length is a string with fixed maximum length
** callers could wrap keys+values and store these with using a cache-key that is md5 of the full key
** it should be possible to implement an optional extra layer (like the multicache) which does this for us
* (Re #6) each cache (namespace/tag) has one TTL, NOT per-element

These changes minimise overheads in code and performance while permitting the most common cache uses.

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init();
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades etc.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-31T00:19:52Z

Tlevi: /* Basic Requirements */ Update with current statis referring to requirement items

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
# it should support different backends (static, session, DB, shared memory...).
# any attempt of caching within Moodle should end using it (and not other solutions).
# code should continue working 100% without caching enabled.
# each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
# each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
# each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

These items have been relaxed or modified somewhat:
* (Re #1) supports multiple backend types, one instance of each type is permitted
** a backend implementation is a 'method', methods implement 'types'
** e.g there is a 'shmem' cache type, which can be backed by either APC or XCache methods
* (Re #2) most caches inside Moodle can use this system, some specialized cases may need to be exempted
* (Re #3) disabling caching is supported, but static cache will remain active in this case for sanity
* (Re #3) elements may disappear at any time from the cache, except static with no size constraint
* (Re #4) Fallback is NOT required, but multiple backends are supported
* (Re #5) callers must provide a unique key for elements, it is their job to form this according to context
** Hashing if needed should be performed inside cache_methods, and collisions must NOT be visible to callers (check full keys too)
* (Re #5) key length is a string with fixed maximum length
** callers could wrap keys+values and store these with using a cache-key that is md5 of the full key
** it should be possible to implement an optional extra layer (like the multicache) which does this for us
* (Re #6) each cache (namespace/tag) has one TTL, NOT per-element

These changes minimise overheads in code and performance while permitting the most common cache uses.

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init();
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades etc.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-30T23:29:59Z

Tlevi: /* Cache interface */ update interface definitions

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
* it should support different backends (static, session, DB, shared memory...).
* any attempt of caching within Moodle should end using it (and not other solutions).
* code should continue working 100% without caching enabled.
* each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
* each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
* each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init(); // returns the singleton
public function get_cache($tag, array $types = array('static'), array $options = array());
public function purge_all();
public function cron();

/* Magic methods for convienience */
public function __isset($name);
public function __get($name);
}
$CACHE = core_cache_manager::init();
</code>

The manager must be able to run a cron and purge for each method, as well as perform get/set operations, this necessitates the following interface for cache methods:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts);
public static function purge_all();
public static function init(); // self-test and initialisation (e.g a DB connection), returns boolean
public static function cron();
public static function type();

public function get($key);
public function put($key, $value); // put(key, null) === remove(key)
public function remove($key);
public function clear();

public function __get($name);
public function __set($name, $value);
public function __isset($name);
public function __unset($name);
}
</code>
...moodle code outside the cache_manager should never touch the static functions, it is not necessary.

For easy implementation of the magic methods, each cache_method should extend this class instead:
<code php>
abstract class cache_method_base implements cache_method_intf {
public function __get($name) {
return $this->get($name);
}
public function __set($name, $value) {
$this->put($name, $value);
}
public function __isset($name) {
return $this->get($name) !== null;
}
public function __unset($name) {
$this->remove($name);
}
}
</code>
This interface allows each method type to run a cron for cleanup purposes and purge_all for upgrades etc.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-30T23:08:00Z

Tlevi: /* Database */ remove database section, this is gone now

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
* it should support different backends (static, session, DB, shared memory...).
* any attempt of caching within Moodle should end using it (and not other solutions).
* code should continue working 100% without caching enabled.
* each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
* each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
* each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init() // returns singleton manager instance
public static function get_cache($tag, array $options = null)
public static function register_method($type, $method)
public static function purge_all()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
}
$CACHE = core_cache_manager::init();
</code>
This is the interface that code within moodle will have to a given cache:
<code php>
abstract class cache_base {
abstract public function get($key)
abstract public function put($key, $value)
abstract public function remove($key) // same as put($key, null)
abstract public function cleanup()
abstract public function clear()
abstract public function size()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
public function __set($name, $value)
public function __unset($name) // same as set($name, null)
}
</code>
...which is used by each cache method and the "multimethod" internal layer.

The cache manager will require extra functions used for housekeeping, so cache methods (plugins) must extend this base:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts)
public static function options()
public static function init()
public static function cron()
public static function type()
}

abstract class cache_method_base extends cache_base implements cache_method_intf {
}
</code>
This interface would allow each method type to run a cron for cleanup purposes.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-24T00:36:39Z

Tlevi: /* Cache list */ fix field length

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
* it should support different backends (static, session, DB, shared memory...).
* any attempt of caching within Moodle should end using it (and not other solutions).
* code should continue working 100% without caching enabled.
* each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
* each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
* each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init() // returns singleton manager instance
public static function get_cache($tag, array $options = null)
public static function register_method($type, $method)
public static function purge_all()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
}
$CACHE = core_cache_manager::init();
</code>
This is the interface that code within moodle will have to a given cache:
<code php>
abstract class cache_base {
abstract public function get($key)
abstract public function put($key, $value)
abstract public function remove($key) // same as put($key, null)
abstract public function cleanup()
abstract public function clear()
abstract public function size()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
public function __set($name, $value)
public function __unset($name) // same as set($name, null)
}
</code>
...which is used by each cache method and the "multimethod" internal layer.

The cache manager will require extra functions used for housekeeping, so cache methods (plugins) must extend this base:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts)
public static function options()
public static function init()
public static function cron()
public static function type()
}

abstract class cache_method_base extends cache_base implements cache_method_intf {
}
</code>
This interface would allow each method type to run a cron for cleanup purposes.

==Database==
===Cache list===
There is a database table to store a list of caches with their tags. The cache information is serialised and stored so setup and options can are preserved.
<code sql>
CREATE TABLE mdl_caches (
id bigint PRIMARY KEY DEFAULT nextval('mdl_caches_id_seq'),
tag varchar(255) NOT NULL,
timemodified bigint NOT NULL,
cacheobj text NOT NULL
);

CREATE UNIQUE INDEX mdl_caches_tag_uix ON mdl_caches (tag);
CREATE INDEX mdl_caches_tim_ix ON mdl_caches (timemodified);
</code>
This allows cron to examine each cache and expire entries (e.g memcache, files, etc) as well as other maintenance.
Currently static-only caches are specially exempt from this table for performance reasons.

TODO: examine if this is possible in a less ugly way.

===DB Cache type===
The DB cache type would have a table structured like the following:
<code sql>
CREATE TABLE mdl_cache_data (
id bigint PRIMARY KEY DEFAULT nextval('mdl_cachedata_id_seq'),
tag varchar(255) NOT NULL,
key varchar(255) NOT NULL,
timeexpire bigint NOT NULL,
value text
);

CREATE UNIQUE INDEX mdl_cachedata_tagkey_uix ON mdl_cache_data (tag, key);
CREATE INDEX mdl_cachedata_expire_ix ON mdl_cache_data (timeexpire);
</code>
The expire field allows cron to auto-expire entries without looking at each cache alone.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-24T00:36:21Z

Tlevi: /* DB Cache type */ fix field length

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
* it should support different backends (static, session, DB, shared memory...).
* any attempt of caching within Moodle should end using it (and not other solutions).
* code should continue working 100% without caching enabled.
* each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
* each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
* each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init() // returns singleton manager instance
public static function get_cache($tag, array $options = null)
public static function register_method($type, $method)
public static function purge_all()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
}
$CACHE = core_cache_manager::init();
</code>
This is the interface that code within moodle will have to a given cache:
<code php>
abstract class cache_base {
abstract public function get($key)
abstract public function put($key, $value)
abstract public function remove($key) // same as put($key, null)
abstract public function cleanup()
abstract public function clear()
abstract public function size()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
public function __set($name, $value)
public function __unset($name) // same as set($name, null)
}
</code>
...which is used by each cache method and the "multimethod" internal layer.

The cache manager will require extra functions used for housekeeping, so cache methods (plugins) must extend this base:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts)
public static function options()
public static function init()
public static function cron()
public static function type()
}

abstract class cache_method_base extends cache_base implements cache_method_intf {
}
</code>
This interface would allow each method type to run a cron for cleanup purposes.

==Database==
===Cache list===
There is a database table to store a list of caches with their tags. The cache information is serialised and stored so setup and options can are preserved.
<code sql>
CREATE TABLE mdl_caches (
id bigint PRIMARY KEY DEFAULT nextval('mdl_caches_id_seq'),
tag varchar(256) NOT NULL,
timemodified bigint NOT NULL,
cacheobj text NOT NULL
);

CREATE UNIQUE INDEX mdl_caches_tag_uix ON mdl_caches (tag);
CREATE INDEX mdl_caches_tim_ix ON mdl_caches (timemodified);
</code>
This allows cron to examine each cache and expire entries (e.g memcache, files, etc) as well as other maintenance.
Currently static-only caches are specially exempt from this table for performance reasons.

TODO: examine if this is possible in a less ugly way.

===DB Cache type===
The DB cache type would have a table structured like the following:
<code sql>
CREATE TABLE mdl_cache_data (
id bigint PRIMARY KEY DEFAULT nextval('mdl_cachedata_id_seq'),
tag varchar(255) NOT NULL,
key varchar(255) NOT NULL,
timeexpire bigint NOT NULL,
value text
);

CREATE UNIQUE INDEX mdl_cachedata_tagkey_uix ON mdl_cache_data (tag, key);
CREATE INDEX mdl_cachedata_expire_ix ON mdl_cache_data (timeexpire);
</code>
The expire field allows cron to auto-expire entries without looking at each cache alone.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-24T00:05:10Z

Tlevi: /* Cache interface */ expand

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
* it should support different backends (static, session, DB, shared memory...).
* any attempt of caching within Moodle should end using it (and not other solutions).
* code should continue working 100% without caching enabled.
* each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
* each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
* each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init() // returns singleton manager instance
public static function get_cache($tag, array $options = null)
public static function register_method($type, $method)
public static function purge_all()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
}
$CACHE = core_cache_manager::init();
</code>
This is the interface that code within moodle will have to a given cache:
<code php>
abstract class cache_base {
abstract public function get($key)
abstract public function put($key, $value)
abstract public function remove($key) // same as put($key, null)
abstract public function cleanup()
abstract public function clear()
abstract public function size()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
public function __set($name, $value)
public function __unset($name) // same as set($name, null)
}
</code>
...which is used by each cache method and the "multimethod" internal layer.

The cache manager will require extra functions used for housekeeping, so cache methods (plugins) must extend this base:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts)
public static function options()
public static function init()
public static function cron()
public static function type()
}

abstract class cache_method_base extends cache_base implements cache_method_intf {
}
</code>
This interface would allow each method type to run a cron for cleanup purposes.

==Database==
===Cache list===
There is a database table to store a list of caches with their tags. The cache information is serialised and stored so setup and options can are preserved.
<code sql>
CREATE TABLE mdl_caches (
id bigint PRIMARY KEY DEFAULT nextval('mdl_caches_id_seq'),
tag varchar(256) NOT NULL,
timemodified bigint NOT NULL,
cacheobj text NOT NULL
);

CREATE UNIQUE INDEX mdl_caches_tag_uix ON mdl_caches (tag);
CREATE INDEX mdl_caches_tim_ix ON mdl_caches (timemodified);
</code>
This allows cron to examine each cache and expire entries (e.g memcache, files, etc) as well as other maintenance.
Currently static-only caches are specially exempt from this table for performance reasons.

TODO: examine if this is possible in a less ugly way.

===DB Cache type===
The DB cache type would have a table structured like the following:
<code sql>
CREATE TABLE mdl_cache_data (
id bigint PRIMARY KEY DEFAULT nextval('mdl_cachedata_id_seq'),
tag varchar(256) NOT NULL,
key varchar(256) NOT NULL,
timeexpire bigint NOT NULL,
value text
);

CREATE UNIQUE INDEX mdl_cachedata_tagkey_uix ON mdl_cache_data (tag, key);
CREATE INDEX mdl_cachedata_expire_ix ON mdl_cache_data (timeexpire);
</code>
The expire field allows cron to auto-expire entries without looking at each cache alone.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-10-24T00:02:46Z

Tlevi: /* Database */ Add DB information (this makes me realise how ugly the current implementation is...)

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
* it should support different backends (static, session, DB, shared memory...).
* any attempt of caching within Moodle should end using it (and not other solutions).
* code should continue working 100% without caching enabled.
* each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
* each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
* each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init() // returns singleton manager instance
public static function get_cache($tag, array $options = null)
public static function register_method($type, $method)
public static function purge_all()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
}
$CACHE = core_cache_manager::init();
</code>
This is the interface that code within moodle will have to a given cache:
<code php>
abstract class cache_base {
abstract public function get($key)
abstract public function put($key, $value)
abstract public function remove($key) // same as put($key, null)
abstract public function cleanup()
abstract public function clear()
abstract public function size()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
public function __set($name, $value)
public function __unset($name) // same as set($name, null)
}
</code>
...which is used by each cache method and the "multimethod" internal layer.

The cache manager will require extra functions used for housekeeping, so cache methods (plugins) must extend this base:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts)
public static function options()
public static function init()
public static function cron()
public static function type()
}

abstract class cache_method_base extends cache_base implements cache_method_intf {
}
</code>
==Database==
===Cache list===
There is a database table to store a list of caches with their tags. The cache information is serialised and stored so setup and options can are preserved.
<code sql>
CREATE TABLE mdl_caches (
id bigint PRIMARY KEY DEFAULT nextval('mdl_caches_id_seq'),
tag varchar(256) NOT NULL,
timemodified bigint NOT NULL,
cacheobj text NOT NULL
);

CREATE UNIQUE INDEX mdl_caches_tag_uix ON mdl_caches (tag);
CREATE INDEX mdl_caches_tim_ix ON mdl_caches (timemodified);
</code>
This allows cron to examine each cache and expire entries (e.g memcache, files, etc) as well as other maintenance.
Currently static-only caches are specially exempt from this table for performance reasons.

TODO: examine if this is possible in a less ugly way.

===DB Cache type===
The DB cache type would have a table structured like the following:
<code sql>
CREATE TABLE mdl_cache_data (
id bigint PRIMARY KEY DEFAULT nextval('mdl_cachedata_id_seq'),
tag varchar(256) NOT NULL,
key varchar(256) NOT NULL,
timeexpire bigint NOT NULL,
value text
);

CREATE UNIQUE INDEX mdl_cachedata_tagkey_uix ON mdl_cache_data (tag, key);
CREATE INDEX mdl_cachedata_expire_ix ON mdl_cache_data (timeexpire);
</code>
The expire field allows cron to auto-expire entries without looking at each cache alone.

==Other==
Things that didn't fit above.

Caching system (proposed)

2011-09-11T13:33:07Z

Tlevi: Initial add, some things clearly missing for the moment

{{draft}}

==Introduction==
This page documents a proposed design for an implementation of [http://tracker.moodle.org/browse/MDL-25290 MDL25290] .

The purpose is to provide a staging area for the design before it is implemented into code, and document the expected functionality.

The caching system should be a general architecture that can support all uses of caching within Moodle

==Basic Requirements==
Things the caching system should or must do:
* it should support different backends (static, session, DB, shared memory...).
* any attempt of caching within Moodle should end using it (and not other solutions).
* code should continue working 100% without caching enabled.
* each use should define one fallback of backend to use so, for example, for caching CFG we could use (shared memory, DB) and the 1st one available is picked.
* each cached element must be hash-based (hash selection will be critical to determine if it's globsl/per user/whatever).
* each cached element must have one TTL

(mostly taken from [http://tracker.moodle.org/browse/MDL-25290 MDL25290], thanks Eloy!)

==Outline==
The caching system shall provide access to a series of different caches, referenced by a ''tag''.
Each cache may store many objects stored within which are referenced by a ''key'' and may utilise several backend storage methods.
Therefore, to refer to a particular cached element requires a (''tag'', ''key'') pair.

Additional options such as default ttl or maximum desired cache size can be passed in an options array when the cache is created.
These 'parameters' are (strong) advisory, and certain backends may ignore or override them where it is necessary.

===Tags===
Tags are simple strings of length less than 256 characters and it is the responsibility of programmers utilising the cache to invent a suitable and unique tag; it is possible a convention could be developed to assist with this. Tags are usually stored in a persistent manner, such that caches may be maintained and referenced at a later time for example a cron job that cleans up expired entries or another piece of code that wishes to use the same cache without constructing it afresh or being fully aware of the original options used.
===Keys===
Similar to tags, keys are also simple strings of length less than 256 characters.

If a longer key is required, it could be possible to, for example, use a hash of the full key as the cache key, and store the full key in the value which allows you to validate that there is no hash collision later.

(Perhaps we could be implemented transparently for length-limited storage methods and save the trouble?)

===Methods===
A cache ''method'' is a particular backend storage engine, these are categorised into ''types''.

A cache method implements a single type, and each type may only have one active implementation. This means code inside moodle may request storage types such as static, database, sharedmem and doesn't need to know about all implementations, or which are available. Whichever method is chosen by the server admin (via $CFG) or default will be transparently used for storage.

Methods are implemented as a new plugin type, so they may be added, upgraded etc like any other plugin within moodle. This allows easy customisation and extension as needed. Core should gradually add the most useful methods by default.

===Cache interface===
Interface to the cache manager from moodle code, which allows to create/access caches and overall maintainance:
<code php>
class core_cache_manager {
public static function init() // returns singleton manager instance
public static function get_cache($tag, array $options = null)
public static function register_method($type, $method)
public static function purge_all()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
}
$CACHE = core_cache_manager::init();
</code>
This is the interface that code within moodle will have to a given cache:
<code php>
abstract class cache_base {
abstract public function get($key)
abstract public function put($key, $value)
abstract public function remove($key) // same as put($key, null)
abstract public function cleanup()
abstract public function clear()
abstract public function size()

/* Magic methods for convienience */
public function __isset($name)
public function __get($name)
public function __set($name, $value)
public function __unset($name) // same as set($name, null)
}
</code>
...which is used by each cache method and the "multimethod" internal layer.

The cache manager will require extra functions used for housekeeping, so cache methods (plugins) must extend this base:
<code php>
interface cache_method_intf {
public static function get_cache($tag, array $opts)
public static function options()
public static function init()
public static function cron()
public static function type()
}

abstract class cache_method_base extends cache_base implements cache_method_intf {
}
</code>
==Database==
Add information about database structures here.

==Other==
Things that didn't fit above.

Turnitin errors

2011-08-08T02:48:33Z

Tlevi: Add 228 code I have just seen

This is a list of the Turnitin Codes, and their descriptions.

== Success States 1-99 ==
*1 General Success State, no errors
*10 FID 1, FCMD 1 – successful, send to login
*11 FID 1, FCMD 2 – successful, do not send to login
*20 FID 2, FCMD 1 – successful, send to login
*21 FID 2, FCMD 2 – successful, do not sent to login
*30 FID 3, FCMD 1 – successful, send to login
*31 FID 3, FCMD 2 – successful, do not send to login
*40 FID 4, FCMD 1,5 – successful, redirect user to assignment creation/modification page
*41 FID 4, FCMD 2 – successful
*42 FID 4, FCMD 3 – successful
*43 FID 4, FCMD 4 – successful
*50 FID 5, FCMD 1 – successful, redirect user to submission page
*51 FID 5, FCMD 2 - successful
*60 FID 6, FCMD 1 - successful
*61 FID 6, FCMD 2 - successful
*70 FID 7, FCMD 1,2 – successful
*70 FID 12, FCMD 1 – successful, redirect to administrator statistics page
*71 FID 8, FCMD 2 - successful
*72 FID 10, FCMD 2 - successful
*73 FID 11, FCMD 2 – successful
*74 FID 0 – successful
*75 FID 9, FCMD 2 - successful

== Data Errors 100-199 ==
*100 Primary account ID missing from URL
*101 No HTTPS - the URL was not transmitted via HTTPS
*102 GMT missing from URL
*103 GMT malformed - the date/time in the URL is bad
*104 Email missing from URL
*105 Email address is not between 5-75 characters
*106 Email address contains whitespace
*107 Email address in URL is malformed
*108 Password in URL contained whitespace
*109 Diagnostic value in URL is bad
*110 MD5 missing from URL
*111 fcmd missing from URL
*112 User first name missing from URL or incorrect length
*113 User last name missing from URL or incorrect length
*114 Class title missing from URL, or not between 5-50 characters
*115 Password is not between 6-12 characters
*116 fid missing from URL, or does not reference existing function
*117 User type missing from URL or is not valid
*118 encrypt value in URL is bad or missing
*119 Paper author’s first name missing or incorrect length
*120 Paper author’s last name missing or incorrect length
*121 Paper title missing – Please make sure to include a paper title before submitting your paper
*122 Paper type missing or invalid
*123 Assignment title missing or incorrect length
*124 ObjectID missing
*125 Password is required for function
*126 Date start and date due is required for function
*127 If one unique ID is used, they must all be used
*128 The class end date parameter is not in the right format. Please make sure that the format is in YYYMMDD.”
*140 Undocumented, but appears to occur when assignment title is too long. Should probably return either 2302 or 123 in this situation.

== Turnitin Database Errors 200-299 ==
*200 Primary account ID for Turnitin not activated to use the API
*201 IP address validation range for Turnitin not configured
*202 Primary account entry not active in Turnitin database
*203 MD5 key missing from Turnitin database
*204 Class does not exist in Turnitin database. Please contact you instructor for further details.
*205 Database error verifying class
*206 Assignment does not exist in Turnitin database for this class. The assignment may have been deleted.
*207 Database error verifying assignment
*208 User is not enrolled in class
*209 Database error verifying user’s enrollment in class
*210 User password does not match user email
*211 Database error verifying objectID
*212 objectID does not exist for this user
*213 objectID does not belong to this user
*214 Filename does not exist for this paper
*215 This primary account ID is not authorized to use this product
*216 Student limit for this account has been reached. Cannot join student to this class.
*217 The product for this account has expired. Please contact your sales agent to renew the product
*218 Database Error inserting unique ID into the database
*219 Unique user id in the database does not match submitted uid
*220 More than one class exists with this title and unique ids must be used in this case
*221 More than one assignment exists with this title and unique ids must be used in this case
*222 User is associated with a different external uid. If you have another user account with the same email address as the user account you are currently using, that could be the cause of the problem. Please try modifying the email address for your current user account to a unique email address and try again.
*223 Cannot verify Blackboard user’s identity within Turnitin. Missing Blackboard user id
*224 Could not verify user as primary instructor for this course
*225 Database error checking if student can view reports
*226 The class you are trying to update could not be found. Please check to make sure that the class exists.
*227 The class you are trying to update has an assignment which ends after the class end date you have specified. Please change you class end date or modify the assignment.
*228 The assignment with the assignment id that you entered does not belong to the class with the class id you entered. Please check to make sure that you are not using a duplicate assignment id.

== Inconsistency Errors 300-399 ==
*300 Your IP address does not fall within the range of accepted IP addresses as specified by your Turnitin account administrator. Please check with your Turnitin account administrator if your IP address needs to be added as an accepted IP address.
*301 Date/time expired – GMT timestamp used in MD5 calculation is off. API calls must have a GMT within 60 minutes of the current GMT
*302 MD5 not authenticated - the MD5 in the URL does not match the MD5 calculated

== Function Errors 400-499 ==
*400 Creating new user failed
*401 Unauthorized access - user exists, but does not belong to correct primary account ID or sub-account ID, do not execute function
*402 User is not an instructor, must be an instructor to run this function
*403 User is not a student, must be a student to run this function
*404 FCMD is not valid
*405 Class title is not unique
*406 Creating new class failed in fid 2
*407 Student failed to join or log in to a class in fid 3
*408 Attempt to join new user to account failed
*409 Function requires POST request
*410 Function requires GET request
*411 Creating/Updating/Deleting assignment failed in fid 4
*412 Assignment title is not unique
*413 Error while trying to save the paper
*414 Originality report not generated yet in fid 6, fcmd 1
*415 Originality score not available yet in fid 6, fcmd 2
*416 Error checking if submission existed for user
*417 Error trying to change user password
*418 Error trying to delete submission
*419 Could not create a new assignment. An assignment with this title already exists for this class and instructor. Please change the assignment title.
*420 Error trying to build up session data for user/class
*421 Error trying to retrieve paper submission info for assignment
*422 Updating user information failed
*423 Updating user information failed because user email was changed to an address that is already associated with an account
*424 Updating class title failed
*425 Error trying to sync grades between servers
*426 Error trying to sync roster between servers
*427 Unable to establish web services session with remove webct server
*428 Unable to create WebCT gradebook column for assignment
*429 Web services parameters error
*430 (This is a general webservices error – there could be a number of different messages that come with it)
*431 Error trying to connect back to the Blackboard web service.
*432 Students are not allowed to view reports in this assignment

== Paper Submission Errors 1000-1099 ==
*1000 The due date for this assignment has passed. Please see your instructor to request a late submission.
*1001 You may not submit a paper to this assignment until the assignment start date
*1002You may not submit a paper to this assignment because the Plagiarism Prevention product is unavailable
*1003You have reached the maximum limit of 10 papers for the InSite demo account
*1004Paper author’s first name missing or incorrect length in URL
*1005Paper author’s last name missing or incorrect length in URL
*1006Paper title missing
*1007The file you have uploaded is too big (TurnItIn site has a note that file size may not exceed 10.48576Mb)
*1008No file uploaded! Please make sure that you have attached the file that you wish to submit before sending the request
*1009Invalid file type! Valid file types are MS Word, Acrobat PDF, Postscript, Text, HTML, WordPerfect (WPD) and Rich Text Format. Please make sure the format of your file is one of the valid file types.
*1010You must submit more than 100 characters of non-whitespace
*1011The paper you are tyring to submit is incorrectly formatted. There seems to be spaces between each letter in your paper. Please try submitting again or contact our helpdesk if the problem persists.
*1012Paper length exceeds limits
*1013You must submit more than 20 words of text
*1014You must select an enrolled student as the author of this paper
*1015You have already submitted a paper to this assignment. Please contact your instructor to request a resubmission
*1016This student has already submitted a paper to this assignment. Please delete the original paper before submitting a new one.
*1017Paper author's first name missing or incorrect length in URL
*1018Paper author's last name missing or incorrect length in URL
*1019Paper title exceeds maximum of 200 characters
*1020 This document cannot be accepted because it contains characters from a character set that is not supported.
*1021 You have already submitted a paper to this assignment. Please contact your instructor to request a resubmission.
*1022 This student has already submitted a portfolio item to this assignment. Please delete the original portfolio item before submitting a new one.
*1023 We're sorry, but we could not read the PDF you submitted. Please make sure that the file is not password protected and contains selectable text rather than scanned images.
*1024 The paper you are tyring to submit does not meet our cirteria for a legitimate paper. Please try submitting again or contact our helpdesk if the problem persists.

== Assignment Creation Errors 2025-2324 ==
*2025 The class name must be between 5-200 characters
*2026 The class enrollment password must be between 4-12 characters
*2027 There was an error processing your request
*2028 The class end date must be within 6 months of the start date
*2029 The end date for this class must occur on or after today
*2030 The end date for this class must occur on or after the start date
*2031 The end date for this class must occur at least 3 months after the start date
*2032 There was an error updating the class end date
*2035 There was an error processing your request
*2036 There was an error processing your request
*2100 User first name missing from URL
*2101 User last name missing from URL
*2102 Email is missing. Please make sure that your email address has been set
*2110 We only allow email addressses with 5-75 characters
*2111 The email address cannot contain white space
*2112 Please make sure you are entering a valid email address. The email address you enter can only contain letters, numbers, and the symbols _ (underscore), - (dash), . (period), ' (apostrophe), and + (plus).”
*2300 You have entered an invalid date!
*2301 You must select a rubric set to user with remediation
*2302 The assignment title must be between 2-100 characters
*2303 The assignment must have a point value between 0 and 1000
*2304 The assignment instructions must be less than 1000 characters
*2305 The start date for this assignment must occur on or after today
*2306 The due date for this assignment must occur on or after the start date
*2307 The due date for this assignment must occur within 6 months of the start date
*2308 When creating your assignment, the post date must occur on or before the class end date. The class end date in Turnitin is by default set to 6 months from the day the class was created. The class end date can be chaned in the class update area in Turnitin
*2309 When creating your assignment, please make sure that the post date is on or after the due date of the assignment
*2310 You must specify a point value for this assignment because this class is using distributed grading
*2314 When modifying your assignment, please make sure that the post date is on or after the due date of the assignment
*2315 There was an error processing your request
*2316 There was an error processing your request
*2317 There was an error processing your request
*2318 You cannot change the search targets because papers have already been submitted to this assignment. You must create a new assignment if you would like to change the search targets
*2319 There was an error processing your request
*2320 There was an error processing your request

----