Bug fix for array type selector causing array aggregation over window frame fail#16653
Bug fix for array type selector causing array aggregation over window frame fail#16653kgyrtkirk merged 7 commits intoapache:masterfrom
Conversation
kgyrtkirk
left a comment
There was a problem hiding this comment.
LGTM
@clintropolis: I think this will be good - however this is close to null / [] / [null] stuff ... do you have any notices?
| if (val != null) { | ||
| NonnullPair<ExpressionType, Object[]> coerced = ExprEval.coerceListToArray( | ||
| Arrays.asList((Object[]) val), | ||
| homogenizeMultiValue |
There was a problem hiding this comment.
wait, actual arrays should never be coerced, this is strictly for multi-value strings, why do we need to coerce here?
There was a problem hiding this comment.
Thanks @clintropolis, Understood. changed it to pass through directly for Object arrays. I checked on few scenarios and they worked fine. Would this not create any problem if the underlying Object is not String or Numeric? I tried Array< Array< String >> and that worked.
| final Class<?> clazz = selector.classOfObject(); | ||
| if (Number.class.isAssignableFrom(clazz) || String.class.isAssignableFrom(clazz)) { | ||
| // Number, String supported as-is. | ||
| if (Number.class.isAssignableFrom(clazz) || String.class.isAssignableFrom(clazz) || Object[].class.isAssignableFrom(clazz)) { |
There was a problem hiding this comment.
i suppose this would have also ended up in the 'else' case, but this seems fine too
Description
This commit fixes the windowed aggregation involving array type selector.
example query (earlier used to fail with a defensive exception):
Key changed/added classes in this PR
DefaultColumnSelectorFactoryMakerExpressionSelectorsThis PR has: