okumin commented on code in PR #5584:
URL: https://github.com/apache/hive/pull/5584#discussion_r1929703259


##########
serde/src/java/org/apache/hadoop/hive/serde2/lazy/LazyHiveDecimal.java:
##########
@@ -36,7 +36,7 @@ public class LazyHiveDecimal extends 
LazyPrimitive<LazyHiveDecimalObjectInspecto
 
   private final int precision;
   private final int scale;
-  private static final byte[] nullBytes = new byte[]{0x0, 0x0, 0x0, 0x0};
+  private static final byte[] nullBytes = new byte[]{'N', 'U', 'L', 'L'};

Review Comment:
   HiveDecimalObjectInspector can return null even though the decimal is 
non-null. That's because [the object inspector dynamically tweaks the 
scale](https://github.com/apache/hive/blob/rel/release-4.0.1/serde/src/java/org/apache/hadoop/hive/serde2/objectinspector/primitive/WritableHiveDecimalObjectInspector.java#L45-L50),
 and [the non-null value can be decoded as 
NULL](https://github.com/apache/hive/blob/rel/release-4.0.1/storage-api/src/java/org/apache/hadoop/hive/common/type/HiveDecimal.java#L1472-L1486).
 I guess that's why only `LazyHiveDecimal` handles NULL. In contrast, others, 
such as `LazyHiveIntervalDayTime`, don't have to handle NULL.
   On the other hand, I would say it is not self-evident that 
`LazyHiveDecimal.writeUTF8` can decide how to encode NULL. That's because a 
specific SerDe might decide the encoding or escaping rules. I'm checking if my 
assumption is true or not



##########
ql/src/test/results/clientpositive/llap/json_serde3.q.out:
##########
@@ -131,7 +143,7 @@ POSTHOOK: type: QUERY
 POSTHOOK: Input: default@json_serde3_2
 #### A masked pattern was here ####
 -2     FALSE   NULL    TRUE    1.23E45 value
--2     false   NULL    true    1.23E45 value
+-2     false   NULL    true    1.23E+45        value

Review Comment:
   Now, I think it is OK.
   Revisiting the test cases, I understand that `E` vs. `E+` is introduced when 
an underlying JSON includes a JSON number and the column is defined as 
`BINARY`. I believe not many tools hit the issue, as it is not a common 
practice to refer to a JSON number as a BINARY type. I also expect no standard 
convention for decoding a JSON number into BINARY.



-- 
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: gitbox-unsubscr...@hive.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: gitbox-unsubscr...@hive.apache.org
For additional commands, e-mail: gitbox-h...@hive.apache.org

Reply via email to