This section covers some details of the caching mechanism which are not discussed in the topics section.
If you are developing plugins and want to modify the caching behavior of your classes, we recommend you read that section first.
There are several methods which the internal classes of AiiDA use to control the caching mechanism:
On the level of the generic orm.Node class:
The is_valid_cache() property determines whether a particular node can be used as a cache.
This is used for example to disable caching from failed calculations.
Node classes have a _cachable attribute, which can be set to False to completely switch off caching for nodes of that class.
This avoids performing queries for the hash altogether.
On the level of the Process and orm.ProcessNode classes:
The ProcessNode.is_valid_cache calls Process.is_valid_cache, passing the node itself.
This can be used in Process subclasses (e.g. in calculation plugins) to implement custom ways of invalidating the cache.
The ProcessNode._hash_ignored_inputs attribute lists the inputs that should be ignored when creating the hash.
This is checked by the ProcessNode._get_objects_to_hash method.
The Process.is_valid_cache is where the exit_codes that have been marked by invalidates_cache are checked.
As discussed in the topic section, nodes which can have RETURN links cannot be cached.
This is enforced on two levels:
The _cachable property is set to False in the Node, and only re-enabled in CalculationNode (which affects CalcJobs and calcfunctions).
This means that a WorkflowNode will not be cached.
The _store_from_cache method, which is used to “clone” an existing node, will raise an error if the existing node has any RETURN links.
This extra safe-guard prevents cases where a user might incorrectly override the _cachable property on a WorkflowNode subclass.