-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18925/#review36644
-----------------------------------------------------------
Ship it!
go for r3 with the getClass (and no instanceof) check and {} formatting.
- justin coffey
On March 8, 2014, 12:01 a.m., Szehon Ho wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18925/
> -----------------------------------------------------------
>
> (Updated March 8, 2014, 12:01 a.m.)
>
>
> Review request for hive, Brock Noland, justin coffey, and Xuefu Zhang.
>
>
> Repository: hive-git
>
>
> Description
> -------
>
> The issue is, as part of select * query, a DeepParquetHiveMapInspector is
> used for one column of an overall parquet-table struct object inspector.
>
> The problem lies in the ObjectInspectorFactory's cache for struct object
> inspector. For performance, there is a cache keyed on an array list, of all
> object inspectors of columns. The second time the query is run, it attempts
> to lookup cached struct inspector. But when the hashmap looks up the part of
> the key consisting of the DeepParquetHiveMapInspector, java calls .equals
> against the existing DeepParquetHivemapInspector. This fails, as the .equals
> method casted the "other" to a "StandardParquetHiveInspector".
>
> Regenerating the .equals and .hashcode from eclipse.
>
> Also adding one more check in .equals before casting, to handle the case if
> another class of object inspector gets hashed to the same hashcode in the
> cache. Then java would call .equals against the other, which in this case is
> not of the same class.
>
>
> Diffs
> -----
>
>
> ql/src/java/org/apache/hadoop/hive/ql/io/parquet/serde/AbstractParquetMapInspector.java
> 1d72747
>
> Diff: https://reviews.apache.org/r/18925/diff/
>
>
> Testing
> -------
>
> Manual testing.
>
>
> Thanks,
>
> Szehon Ho
>
>
