[
https://issues.apache.org/jira/browse/HIVE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329418#comment-14329418
]
Mithun Radhakrishnan commented on HIVE-9322:
--------------------------------------------
@[~ashutoshc]: You're right about the deja vu. :]
https://issues.apache.org/jira/browse/HIVE-6389?focusedCommentId=13917716&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13917716
(The problem in HIVE-6389 was that we were returning -1, when the data was
NULL, even if it wasn't an integer-map. We discussed the data vs key null-check
as an aside.)
At the moment, the semantics aren't uniform across OIs. {{LazyBinaryMapOI}} and
{{DeepParquetHiveMapOI}} already guard against null-keys, while the others
don't. Wouldn't uniformity be best? In light of your performance concern,
should we consider removing the null-checks in all MapOIs?
I don't think we're changing semantics of what can be stored in a Map because
I'd expect an NPE when writing a null-key (although I might be mistaken). We're
only guarding against non-deterministic behaviour for stuff like:
{code:sql}
SELECT map_column[ string_column ] FROM my_table;
{code}
... in cases where {{string_column IS NULL}}.
> Make null-checks consistent for MapObjectInspector subclasses.
> --------------------------------------------------------------
>
> Key: HIVE-9322
> URL: https://issues.apache.org/jira/browse/HIVE-9322
> Project: Hive
> Issue Type: Bug
> Components: Serializers/Deserializers
> Affects Versions: 0.14.0
> Reporter: Mithun Radhakrishnan
> Assignee: Mithun Radhakrishnan
> Priority: Minor
> Attachments: HIVE-9322.1.patch
>
>
> {{LazyBinaryMapObjectInspector}}, {{DeepParquetHiveMapInspector}}, etc. check
> both the map-column value and the map-key for null, before dereferencing
> them. {{OrcMapObjectInspector}} and {{LazyMapObjectInspector}} do not.
> This patch brings them all in sync. Might not be a real problem, unless (for
> example) the lookup key is itself a (possibly null) value from another column.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
