|
|
|
using Recyclarr.TrashGuide.CustomFormat;
|
|
|
|
|
|
|
|
namespace Recyclarr.Cli.Tests.Pipelines.CustomFormat.Models;
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
[Parallelizable(ParallelScope.All)]
|
|
|
|
public class CustomFormatDataComparerTest
|
|
|
|
{
|
|
|
|
[Test]
|
|
|
|
public void Custom_formats_equal()
|
|
|
|
{
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
var b = CreateMockCustomFormatData();
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().BeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Custom_formats_not_equal_when_field_value_different()
|
|
|
|
{
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
var b = CreateMockCustomFormatData() with
|
|
|
|
{
|
|
|
|
Specifications = a
|
|
|
|
.Specifications.Select(spec =>
|
|
|
|
spec with
|
|
|
|
{
|
|
|
|
Name = spec.Name == "WEBRIP" ? "WEBRIP2" : spec.Name,
|
|
|
|
}
|
|
|
|
)
|
|
|
|
.ToList(),
|
|
|
|
};
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().NotBeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Equal_when_ignored_fields_are_different()
|
|
|
|
{
|
|
|
|
var a = new CustomFormatData
|
|
|
|
{
|
|
|
|
TrashId = "a",
|
|
|
|
TrashScores = { ["default"] = 1 },
|
|
|
|
Category = "one",
|
|
|
|
};
|
|
|
|
|
|
|
|
var b = new CustomFormatData
|
|
|
|
{
|
|
|
|
TrashId = "b",
|
|
|
|
TrashScores = { ["default"] = 2 },
|
|
|
|
Category = "two",
|
|
|
|
};
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().BeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Not_equal_when_right_is_null()
|
|
|
|
{
|
|
|
|
var a = new CustomFormatData();
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
CustomFormatData? b = null;
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().NotBeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Not_equal_when_left_is_null()
|
|
|
|
{
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
CustomFormatData? a = null;
|
|
|
|
var b = new CustomFormatData();
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().NotBeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Equal_for_same_reference()
|
|
|
|
{
|
|
|
|
var a = new CustomFormatData();
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().BeEquivalentTo(a, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Not_equal_when_different_spec_count()
|
|
|
|
{
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
|
|
|
|
var b = a with
|
|
|
|
{
|
|
|
|
Specifications = a
|
|
|
|
.Specifications.Concat([new CustomFormatSpecificationData()])
|
|
|
|
.ToList(),
|
|
|
|
};
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().NotBeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Not_equal_when_non_matching_spec_names()
|
|
|
|
{
|
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
|
|
|
|
var b = a with
|
|
|
|
{
|
|
|
|
Specifications = a
|
|
|
|
.Specifications.Select(spec =>
|
|
|
|
spec with
|
|
|
|
{
|
|
|
|
Name = spec.Name == "WEBRIP" ? "WEBRIP2" : spec.Name,
|
|
|
|
}
|
|
|
|
)
|
|
|
|
.ToList(),
|
|
|
|
};
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().NotBeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
[Test]
|
|
|
|
public void Not_equal_when_different_spec_names_and_values()
|
|
|
|
{
|
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
var b = a with
|
|
|
|
{
|
|
|
|
Specifications = a
|
|
|
|
.Specifications.Select(spec =>
|
|
|
|
spec with
|
|
|
|
{
|
|
|
|
Name = spec.Name == "WEBRIP" ? "UNIQUE_NAME" : spec.Name,
|
|
|
|
Fields = spec
|
|
|
|
.Fields.Select(field =>
|
|
|
|
field with
|
|
|
|
{
|
|
|
|
Value = field.Value is int ? 99 : "NEW_VALUE",
|
|
|
|
}
|
|
|
|
)
|
|
|
|
.ToList(),
|
|
|
|
}
|
|
|
|
)
|
|
|
|
.ToList(),
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
};
|
|
|
|
|
|
|
|
a.Should().NotBeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
public void Equal_when_different_field_counts_but_same_names_and_values()
|
|
|
|
{
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
var b = a with
|
|
|
|
{
|
|
|
|
Specifications = a
|
|
|
|
.Specifications.Select(spec =>
|
|
|
|
spec with
|
|
|
|
{
|
|
|
|
Fields = spec
|
|
|
|
.Fields.Concat(
|
|
|
|
[
|
|
|
|
new CustomFormatFieldData
|
|
|
|
{
|
|
|
|
Name = "AdditionalField",
|
|
|
|
Value = "ExtraValue",
|
|
|
|
},
|
|
|
|
]
|
|
|
|
)
|
|
|
|
.ToList(),
|
|
|
|
}
|
|
|
|
)
|
|
|
|
.ToList(),
|
|
|
|
};
|
|
|
|
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
a.Should().BeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Equal_when_specifications_order_different()
|
|
|
|
{
|
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
|
|
|
|
var b = a with { Specifications = a.Specifications.Reverse().ToList() };
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
|
|
|
|
a.Should().BeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[Test]
|
|
|
|
public void Equal_when_fields_order_different_for_each_specification()
|
|
|
|
{
|
|
|
|
var a = CreateMockCustomFormatData();
|
|
|
|
|
|
|
|
var b = a with
|
|
|
|
{
|
|
|
|
Specifications = a
|
|
|
|
.Specifications.Select(spec =>
|
|
|
|
spec with
|
|
|
|
{
|
|
|
|
Fields = spec.Fields.Reverse().ToList(),
|
|
|
|
}
|
|
|
|
)
|
|
|
|
.ToList(),
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
};
|
|
|
|
|
|
|
|
a.Should().BeEquivalentTo(b, o => o.ComparingRecordsByValue());
|
|
|
|
}
|
|
|
|
|
|
|
|
[TestCase(typeof(CustomFormatData))]
|
|
|
|
[TestCase(typeof(CustomFormatSpecificationData))]
|
|
|
|
public void Throws_exception_when_used_as_key_in_dictionary(Type type)
|
|
|
|
{
|
|
|
|
var act = () =>
|
|
|
|
new Dictionary<object, object?>().Add(Activator.CreateInstance(type)!, null);
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
|
|
|
|
act.Should().Throw<NotImplementedException>();
|
|
|
|
}
|
|
|
|
|
|
|
|
[TestCase(typeof(CustomFormatData))]
|
|
|
|
[TestCase(typeof(CustomFormatSpecificationData))]
|
|
|
|
public void Throws_exception_when_used_as_key_in_hash_set(Type type)
|
|
|
|
{
|
|
|
|
var act = () => new HashSet<object>().Add(Activator.CreateInstance(type)!);
|
|
|
|
|
|
|
|
act.Should().Throw<NotImplementedException>();
|
|
|
|
}
|
|
|
|
|
|
|
|
private static CustomFormatData CreateMockCustomFormatData()
|
|
|
|
{
|
|
|
|
return new CustomFormatData
|
|
|
|
{
|
|
|
|
Name = "EVO (no WEBDL)",
|
|
|
|
IncludeCustomFormatWhenRenaming = false,
|
|
|
|
Specifications =
|
|
|
|
[
|
|
|
|
new CustomFormatSpecificationData
|
|
|
|
{
|
|
|
|
Name = "EVO",
|
|
|
|
Implementation = "ReleaseTitleSpecification",
|
|
|
|
Negate = false,
|
|
|
|
Required = true,
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
Fields = new List<CustomFormatFieldData>
|
|
|
|
{
|
|
|
|
new() { Name = "value", Value = @"\bEVO(TGX)?\b" },
|
|
|
|
new() { Name = "foo1", Value = "foo1" },
|
|
|
|
},
|
|
|
|
},
|
|
|
|
new CustomFormatSpecificationData
|
|
|
|
{
|
|
|
|
Name = "WEBDL",
|
|
|
|
Implementation = "SourceSpecification",
|
|
|
|
Negate = true,
|
|
|
|
Required = true,
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
Fields = new List<CustomFormatFieldData>
|
|
|
|
{
|
|
|
|
new() { Name = "value", Value = 7 },
|
|
|
|
new() { Name = "foo2", Value = "foo2" },
|
|
|
|
},
|
|
|
|
},
|
|
|
|
new CustomFormatSpecificationData
|
|
|
|
{
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
Name = "WEBRIP",
|
|
|
|
Implementation = "LanguageSpecification",
|
|
|
|
Negate = true,
|
|
|
|
Required = true,
|
fix: Better change detection for CF specification fields
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.
5 months ago
|
|
|
Fields = new List<CustomFormatFieldData>
|
|
|
|
{
|
|
|
|
new() { Name = "value", Value = 8 },
|
|
|
|
new() { Name = "exceptLanguage", Value = false },
|
|
|
|
new() { Name = "foo3", Value = "foo3" },
|
|
|
|
},
|
|
|
|
},
|
|
|
|
],
|
|
|
|
};
|
|
|
|
}
|
|
|
|
}
|