cheddar commented on code in PR #13086:
URL: https://github.com/apache/druid/pull/13086#discussion_r977146336
##########
extensions-contrib/compressed-bigdecimal/src/main/java/org/apache/druid/compressedbigdecimal/CompressedBigDecimal.java:
##########
@@ -274,13 +276,74 @@ protected static <S> int signumInternal(int size, S rhs,
ToIntBiFunction<S, Inte
/* (non-Javadoc)
* @see java.lang.Comparable#compareTo(java.lang.Object)
*/
+
@Override
public int compareTo(CompressedBigDecimal o)
+ {
+ return compareTo(o, false);
+ }
+ public int compareTo(CompressedBigDecimal o, boolean expectOptimized)
Review Comment:
Heh, he's not doing it that way because I hate the `VisibleForTesting`
annotation and adjusting the visibility only creates friction for the future
without actually protecting anything. Those things combine to just pretend
like the method is not part of the actual contract of the object when it is.
In this case, there is basically a "strict" version that expects that
objects have already been aligned so that we can use a more optimal code path.
But there's a more loose version as well that just "does the right thing". We
have the tests that exercise this via queries only use the "strict" version
because the normal query pipeline should be aligning things so that the more
optimal code path is followed, but in production the non-strict version is
actually used just in case. I.e. the tests are there to catch against
regressions when running through queries, but there are other tests that also
leverage the whole thing. In all, the "contract" of the object requires us to
have both, otherwise we cannot test it. There also might be a case in
production where we want to blow up if there is a mis-alignment, in that case,
this method is a great way to achieve that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
