Refresh¶
Dataface Cloud
This page describes Dataface Cloud, the hosted
product — these features are not part of the open source dft
engine.
A dashboard's charts run queries against your database. Refresh policy decides when those queries actually re-run, versus when a viewer sees a cached result.
What's Cloud-owned¶
Scheduling a dashboard to refresh on a cadence — how often, what timezone, whether it's triggered by an event instead of a clock, how retries and concurrent runs are handled, who gets notified — is Cloud behavior. None of that configuration lives in your project's YAML or git history; it's set and changed in Cloud, the same way access is, and it's keyed to a dashboard's path.
Who can trigger a refresh follows the same path-based access model as viewing and editing: refreshing is one of the capabilities a role can carry, so whoever holds an Editor-level (or custom) grant with that capability at a path can refresh it.
What core gives you¶
Running Dataface on its own — dft serve or dft render — you control
freshness directly through the query-result cache. By default the cache is
in-memory and lasts only as long as the server process; every restart is a
clean refresh. Point --cache <path> (or DFT_CACHE_PATH) at a file to
persist the cache across restarts, or pass --no-cache to re-run every query
on every request. See the dft serve reference for the
full set of caching flags.
Cloud's scheduler builds on top of these same primitives — it's the thing deciding when to invalidate and re-run, not a different query or storage mechanism underneath.
Related¶
- Access control — the path-based model refresh permissions follow
dft servereference — cache flags for local development