Default Cache Control Policy

A default Cache Control Policy is applied to manage the caching behavior of the system, in other words, it controls how data is read.

The defaults are set as follows:

  • Cache Policy for Reads: read from cache then device
  • Read Before Write: On Update
  • Read After Write: On Add
  • Read After Write: On Update
  • Model specific overrrides:
    • Model Type: device/notification_service/*
      • Cache Policy for Reads: Cache

The following concepts apply:

  • Cache only: Unless overridden within the request, instance reads via the API always return the cached version of data. There is no need for the client to query the uncached instance data.

  • Cache then device: The API will return the cached data, the Admin Portal will indicate that the data shown is cached and will automatically make an API call requesting non-cached data. It is up to external clients to query the data requesting non-cached data. If this option is selected, data is loaded into the system in two steps:

    1. Load cached data
    2. Load device data

    The ‘cached’ visual indicator is displayed until the second step is complete.

    The device data overrides the previously displayed data unless the user has made an input:

    1. The fields changed by the user will reflect the user’s input and not the device data.
    2. Arrays are blocked for the duration of the device data loading (while the ‘cached’ flag is displayed) and the user can not add or remove elements until the device data loading completes.

    Data is validated constantly as displayed values change, and validation status always reflects the very latest state.

  • Manual: Unless overridden within the request, instance reads via the API always return the cached version of data. An external client using the API needs to provide a button to allow the user to manually retrieve non-cached data.

  • No cache: Unless overridden within the request, instance reads via the API always return the uncached version of data that is queried from the device. In this mode the Admin Portal will not show any data until it is retrieved from the device.

For Relation model types, the relation’s cache control policy will filter down to the joined device models. For example:

  • If the cache control policy of a Relation is Cache then Device, any GET operations that do not specify the cached parameter will return a cached result. It then becomes the client’s responsibility to make another request with cached=false.
  • If the cache control policy of a Relation is Cache only or Manual, then any GET requests that do not specify the cached parameter, return cached data for all joined models.
  • If the cache control policy on read is No cache, the Relation will always fetch the latest device data.