New comparison condition

[shellcromancer]

Is your feature request related to a problem? Please describe.
With substation today, it's not possible to conditionally set a value based on how two keys from the input relate to each other, this is where a compare condition could help. This is useful when comparing values in an array before and after a copy using a gjson selection to a metadata key and setting output based on that result.

Describe the solution you'd like
A new compare condition compare parts of the JSON with itself like described above and we'd probably to support comparisons (across datatypes integers, strings, floats, and booleans) in the form of:

• equals,
• greaterthan,
• greaterthanequals,
• lessthan,
• lessthanequals

Describe alternatives you've considered
We could not support this, after introducing the for_each condition similar problems can be solved more directly.

Additional context
The implementation for this could likely borrow code from the length inspector/condition, the only difference is we are comparing another input value instead of a static literal.

[jshlbrd]

@rafaelbreno If you're interested in a contribution that requires design work, then this would be a good issue to take. This feature would be similar to https://github.com/brexhq/substation/blob/main/condition/strings.go and https://github.com/brexhq/substation/blob/main/condition/length.go, except that instead of doing the comparison against a static value put into the configuration, the comparison uses a second key from the JSON.

[rafaelbreno]

@jshlbrd I'll take a look, thanks for assigning! :D

[jshlbrd]

Had a chat with @Mallika05 and since the redesign I think the way forward with this is to add object.target_key support to the existing inspectors that check against a static value (they all have the value field). This works because:

• It reuses the existing semantics of how the system is configured, so we aren't introducing an entirely new concept
• It keeps the code simple and reduces function sprawl -- if this were an entirely new set of inspectors (compare.string, compare.int, etc.), then we'd have to keep it updated and add more configurable logic any time we introduce new sub-functions (like feat(condition): Add Number Greater Than Inspector #183 and feat(condition): Add Number Less Than Inspector #186).

Here's an example of how to do it. If this is the existing string_equal_to inspector:

	if insp.conf.Object.SourceKey == "" {
		return bytes.Equal(msg.Data(), insp.b), nil
	}

	value := msg.GetValue(insp.conf.Object.SourceKey)
	return bytes.Equal(value.Bytes(), insp.b), nil

Then this is the updated code that supports comparison with another field:

	if insp.conf.Object.SourceKey == "" {
		return bytes.Equal(msg.Data(), insp.b), nil
	}

	// This must be copied so that the original configured value
	// is available for use by any new call to the method.
	compare := insp.b

	// If the value doesn't exist, then the configured value
	// is used in the check.
	target := msg.GetValue(insp.conf.Object.TargetKey)
	if target.Exists() {
		compare = target.Bytes()
	}

	value := msg.GetValue(insp.conf.Object.SourceKey)
	return bytes.Equal(value.Bytes(), compare), nil