Sorry, something went wrong.
| } else if (i1 == null) { | ||
| return -1; | ||
| return nullMeansEqual ? 0 : -1; | ||
| } else if (i2 == null) { |
There was a problem hiding this comment.
Don't we need to check nullMeansEqual here so that comparetoWithNulls is symmetric?
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry, I don't get it...
Sorry, something went wrong.
There was a problem hiding this comment.
Shouldn't i2 be treated same way as i1 so that if i2 is null you check nullMeansEqual
Sorry, something went wrong.
There was a problem hiding this comment.
Ah.
I thought about this a lot yesterday. The thing is - we are not implementing the normal compareTo method, but we implement something which is only used by isGreaterOrEqualTo and isLessOrEqualTo.
For these 2 cases I think the comparison order is important, because the lazier "equal" depends on the base version to have a null.
Example:
Technically, when comparing 3.1.7 with 3.1.7.3085, 3.1.7 is less and not equal. That's how the comparison was before (null being treated as 0 basically).
But that's not what I want when using isGreaterOrEqualTo - I want this function to be forgiving if I only provide 3.1.7 as base, so any number in the 4th level of the comparison should be treated as being equal.
On the other hand, when I provide a specific base (e.g. 3.1.7.3085), I really expect it to be precise, so I can't treat i2 the same way in that case.
Maybe I should not use parameters here and instead write the isGreaterOrEqualTo function separately so it's more clear we're not implementing a strict compareTo here.
Sorry, something went wrong.
This removes the necessity for several different TestRunnerStatements, adding all functionality into one Statement with a dynamic Parameterlist.
It's now very clear which features are supported by which utPLSQL version.
Also, NULL-parameters are now handled much better, allowing the core to deal with defaults.
Fixes #92