From eacbec9c68abf344575fa08e59104d2c4e64a74d Mon Sep 17 00:00:00 2001 From: Jeremy Stretch Date: Thu, 30 Jul 2020 14:57:34 -0400 Subject: [PATCH] Update caching, change logging documentation --- docs/additional-features/caching.md | 28 ++++++++++++---------- docs/additional-features/change-logging.md | 8 +++---- 2 files changed, 20 insertions(+), 16 deletions(-) diff --git a/docs/additional-features/caching.md b/docs/additional-features/caching.md index 0e6513602..359d65202 100644 --- a/docs/additional-features/caching.md +++ b/docs/additional-features/caching.md @@ -1,21 +1,25 @@ # Caching -To improve performance, NetBox supports caching for most object and list views. Caching is implemented using Redis, -and [django-cacheops](https://github.com/Suor/django-cacheops) +NetBox supports database query caching using [django-cacheops](https://github.com/Suor/django-cacheops) and Redis. When a query is made, the results are cached in Redis for a short period of time, as defined by the [CACHE_TIMEOUT](../../configuration/optional-settings/#cache_timeout) parameter (15 minutes by default). Within that time, all recurrences of that specific query will return the pre-fetched results from the cache. -Several management commands are avaliable for administrators to manually invalidate cache entries in extenuating circumstances. +If a change is made to any of the objects returned by the query within that time, or if the timeout expires, the results are automatically invalidated and the next request for those results will be sent to the database. -To invalidate a specifc model instance (for example a Device with ID 34): -``` -python netbox/manage.py invalidate dcim.Device.34 +## Invalidating Cached Data + +Although caching is performed automatically and rarely requires administrative intervention, NetBox provides the `invalidate` management command to force invalidation of cached results. This command can reference a specific object my its type and numeric ID: + +```no-highlight +$ python netbox/manage.py invalidate dcim.Device.34 ``` -To invalidate all instance of a model: -``` -python netbox/manage.py invalidate dcim.Device +Alternatively, it can also delete all cached results for an object type: + +```no-highlight +$ python netbox/manage.py invalidate dcim.Device ``` -To flush the entire cache database: -``` -python netbox/manage.py invalidate all +Finally, calling it with the `all` argument will force invalidation of the entire cache database: + +```no-highlight +$ python netbox/manage.py invalidate all ``` diff --git a/docs/additional-features/change-logging.md b/docs/additional-features/change-logging.md index b359f9b26..d580ccc6c 100644 --- a/docs/additional-features/change-logging.md +++ b/docs/additional-features/change-logging.md @@ -1,9 +1,9 @@ # Change Logging -Every time an object in NetBox is created, updated, or deleted, a serialized copy of that object is saved to the database, along with meta data including the current time and the user associated with the change. These records form a running changelog both for each individual object as well as NetBox as a whole (Organization > Changelog). +Every time an object in NetBox is created, updated, or deleted, a serialized copy of that object is saved to the database, along with meta data including the current time and the user associated with the change. These records form a persistent record of changes both for each individual object as well as NetBox as a whole. The global change log can be viewed by navigating to Other > Change Log. -A serialized representation is included for each object in JSON format. This is similar to how objects are conveyed within the REST API, but does not include any nested representations. For instance, the `tenant` field of a site will record only the tenant's ID, not a representation of the tenant. +A serialized representation of the instance being modified is included in JSON format. This is similar to how objects are conveyed within the REST API, but does not include any nested representations. For instance, the `tenant` field of a site will record only the tenant's ID, not a representation of the tenant. -When a request is made, a random request ID is generated and attached to any change records resulting from the request. For example, editing multiple objects in bulk will create a change record for each object, and each of those objects will be assigned the same request ID. This makes it easy to identify all the change records associated with a particular request. +When a request is made, a UUID is generated and attached to any change records resulting from that request. For example, editing three objects in bulk will create a separate change record for each (three in total), and each of those objects will be associated with the same UUID. This makes it easy to identify all the change records resulting from a particular request. -Change records are exposed in the API via the read-only endpoint `/api/extras/object-changes/`. They may also be exported in CSV format. +Change records are exposed in the API via the read-only endpoint `/api/extras/object-changes/`. They may also be exported via the web UI in CSV format.