I've made some updates to Recyclarr's CF "field" handling for
specifications, specifically addressing the issues regarding processing
language specifications
Here's a quick rundown of how Recyclarr processes fields for a language
spec after this change:
When loading the following fields from the guide:
```json
"fields": {
"value": 8,
"exceptLanguage": false
}
```
Recyclarr transforms it into the API-compatible format:
```json
"fields": [
{
"name": "value",
"value": 8
},
{
"name": "exceptLanguage",
"value": false
}
]
```
Next, it retrieves CF data from the API. For instance, if the API
returns:
```json
"fields": [
{
"name": "value",
"value": 10
},
{
"name": "foo",
"value": "bar"
},
{
"name": "exceptLanguage",
"value": true
}
]
```
Recyclarr compares the two sets of fields by matching the `name`
attributes from the guide to those from the API. Any fields present in
the API but absent in the guide are ignored. The values for matching
fields are then updated accordingly, and these changes are pushed back.
For this example:
- The field `value` is updated from `8` to `10`.
- The field `exceptLanguage` is updated from `false` to `true`.
- The field `foo` is ignored since there's no corresponding field in the
guide.
The cache system has been redesigned for extensibility and to support
caching data beyond Custom Formats. This is motivated by plans to cache
Quality Profiles to support the ability to do things like rename
profiles.
To simplify logic in the system, a child lifetime scope is created for
each distinct configuration instance that is processed by Recyclarr. The
main driver for this is to avoid objects being reused between instances
and thus needing setup & teardown logic to deal with state.
- `CustomFormatCache` is now a utility class for updating cache entries.
- `CustomFormatCacheData` is now what `CustomFormatCache` used to be
(data object used for serialization).
- `CustomFormatCachePersister` is now specific to custom formats. Future
cache types will have their own persister implementation.
Robert Dailey