clintropolis commented on code in PR #12953:
URL: https://github.com/apache/druid/pull/12953#discussion_r955844900
##########
processing/src/main/java/org/apache/druid/segment/LongDimensionIndexer.java:
##########
@@ -47,7 +48,7 @@ public class LongDimensionIndexer implements
DimensionIndexer<Long, Long, Long>
public EncodedKeyComponent<Long>
processRowValsToUnsortedEncodedKeyComponent(@Nullable Object dimValues, boolean
reportParseExceptions)
{
if (dimValues instanceof List) {
- throw new UnsupportedOperationException("Numeric columns do not support
multivalue rows.");
+ throw new ParseException(null, "Numeric columns do not support
multivalue rows.");
}
Review Comment:
>Users are most likely to run into this scenario where they are ingesting
the data directly without transforms in between.
I guess that was just an example I was using to show that the space of
things that can appear here is potentially very large. The indexers are
entirely at the whims of whatever is underneath it is spitting out. We try to
make things nice and tidy, but I can think of a couple very recent bug fixes
which were about strange types ending up in places because of the behavior of
the input format, #12828 and #12873.
>If you are saying that we should be returning similar error messages for
other types too, I agree. but in absence of that, we do the best we can.
heh, I guess I was thinking the opposite, i don't think we can anticipate
everything we could see here and so it seems strange to single out some subset
with unique messages.
Seeing the value that wasn't a number seems like the most useful thing to
have in the error message, since I can see that an array is obviously not a
long, regardless of what the java type is (though the java type is important to
be in the log message to help with bug reports).
>I was thinking along similar lines but thought that it might be overkill.
Hopefully having some clean error messages/error codes soon will help in these
situations.
It seems like overkill to me 😅
--
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]
