Feature/Updated validation to allow for missing sigma

[Jerry-Jinfeng-Guo]

Updated the validation, test and documentation.

[Jerry-Jinfeng-Guo]

I'll happily make the changes and switch to another incremental approach if the whole team agrees @mgovers @petersalemink95 @TonyXiang8787 . Else I'll stick to my approach, and perhaps simplify some of the code to reduce reading complexity.

Summary:
The issue relates to the check regarding the power_sigma inside *sym_power_sensor. Previously it lives inside required::*sym_power_sensor. Since data input can contain multitude of such sensors, I proposed the solution to tailor the required field to data. Martijn suggested that they should be checked next to the regular required check, by first removing them from required entirely and then followed by a dedicated power_sigma/p_sigma/q_sigma check.

While I agree with Martijn's comment on part of the code's reading complexity, I do not see this incremental check for every new feature as a better solution. I stand corrected. Could use some input here, thanks in advance!

[TonyXiang8787]

@mgovers @Jerry-Jinfeng-Guo My proposal is to push this with minimal necessary refactoring. Do not change the logic of how validation function works unless it is really needed.

[mgovers]

@mgovers @Jerry-Jinfeng-Guo My proposal is to push this with minimal necessary refactoring. Do not change the logic of how validation function works unless it is really needed.

it feels like we're building up some serious tech debt here that may make changes harder in the future and sets a precedent. what's your rationale?

[TonyXiang8787]

@mgovers @Jerry-Jinfeng-Guo My proposal is to push this with minimal necessary refactoring. Do not change the logic of how validation function works unless it is really needed.

it feels like we're building up some serious tech debt here that may make changes harder in the future and sets a precedent. what's your rationale?

My rationale is that we might one day move the whole validation process in C++ core (but still separate optional function in C API) with semi-automatically generated code based on the pre-defined attributes constraints.

[mgovers]

@mgovers @Jerry-Jinfeng-Guo My proposal is to push this with minimal necessary refactoring. Do not change the logic of how validation function works unless it is really needed.

it feels like we're building up some serious tech debt here that may make changes harder in the future and sets a precedent. what's your rationale?

My rationale is that we might one day move the whole validation process in C++ core (but still separate optional function in C API) with semi-automatically generated code based on the pre-defined attributes constraints.

while i very much like that, that don't believe that that's anywhere near prioritized by @petersalemink95 now

[petersalemink95]

@mgovers @Jerry-Jinfeng-Guo My proposal is to push this with minimal necessary refactoring. Do not change the logic of how validation function works unless it is really needed.

it feels like we're building up some serious tech debt here that may make changes harder in the future and sets a precedent. what's your rationale?

My rationale is that we might one day move the whole validation process in C++ core (but still separate optional function in C API) with semi-automatically generated code based on the pre-defined attributes constraints.

while i very much like that, that don't believe that that's anywhere near prioritized by @petersalemink95 now

I think this wil happen in the long future. For now, I'd like to keep the code similar everywhere and not make new tech dept for different checks. We can do them all in a similar way as has been done before

[Jerry-Jinfeng-Guo]

@mgovers @Jerry-Jinfeng-Guo My proposal is to push this with minimal necessary refactoring. Do not change the logic of how validation function works unless it is really needed.

it feels like we're building up some serious tech debt here that may make changes harder in the future and sets a precedent. what's your rationale?

My rationale is that we might one day move the whole validation process in C++ core (but still separate optional function in C API) with semi-automatically generated code based on the pre-defined attributes constraints.

while i very much like that, that don't believe that that's anywhere near prioritized by @petersalemink95 now

I think this wil happen in the long future. For now, I'd like to keep the code similar everywhere and not make new tech dept for different checks. We can do them all in a similar way as has been done before

Well, I will ask for some clearance here then: my proposed solution (A) and Martijn's opinion (B) are both trying to do just this, but from different perspective. Mine kept the original checks and only made it more tailored; Marthijn's follows existing paradigm of incrementally adding new checks whenever there are new features needed special treatment. In a way, this is the result of keeping the same goal but with different interpretations. So here comes the question, A or B? @TonyXiang8787 @petersalemink95

[TonyXiang8787]

@Jerry-Jinfeng-Guo @mgovers @petersalemink95 the situation about power_sigma, p_sigma and q_sigma is really exceptional. Making some tailored code for that would not build much technical debt, I think.

So I am in favor of @Jerry-Jinfeng-Guo's current solution.

[mgovers]

love it. just some minor remarks and hopefully we can get this out the door today

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
98.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud