Added caching setting to GeneratorConfiguration

[kolodkinvalentin]

Hi! I encountered an incorrect behavior when using $ref references. There are two fields in the schema that reference the same subschema. First field is marked as required, and the second is not. In the generated class, the second field is mistakenly set as required.
I suggest considering the "cacheEnabled" setting to solve the problem, as the easiest way.

[coveralls]

Pull Request Test Coverage Report for Build 11722352622

Details

• 6 of 6 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.002%) to 98.815%

---

Totals
Change from base Build 10959142369:	0.002%
Covered Lines:	2919
Relevant Lines:	2954

---

💛 - Coveralls

[wol-soft]

Hi,

thanks for the finding, nice edge case. I don't think adding a configuration value is the correct approach to solve this isue as there is no doubt whether the handling is wrong or right. This should be solved in the library without the need for further configuration like "Yeah, I want the library to behave correctly".

The issue should also occur for different schema dependencies on properties using the same $ref as the implementation as well as the required flag relies on the information provided by the PropertyMetaDataCollection (should also be a test case I think).

From my point of view it's more related to external information added to the $ref which consequently should be added to the cache key (basically a hash over the PropertyMetaDataCollection by attribute) instead of the configuration.

Regarding the test cases, I've added an Issue section to the test suite recently, to ensure test cases can be linked to the corresponding issue/MR here on GitHub. Would be nice, to have an Issue86Test there instead of adding them to existing classes ;)

Cheers!

[wol-soft]

@kolodkinvalentin are you going to adjust the patch or should I implement a fix for the issue?

[kolodkinvalentin]

I would like to, but unfortunately I don't have enough time. If you do I will be very grateful.

For now I solve the problem by changing the scheme, swapping the required and optional properties. It helps to get around the problem by making the optional property higher than the required one.

[wol-soft]

Alright, I'll have a look at it. Good to hear, you've found a temporary workaround until it's finished.

[wol-soft]

Tagged version 0.25.1 including the fix using the hash method for the PropertyMetaDataCollection. Also added test cases for both, required and dependencies metadata.