Re: [PR] NIFI-13744 2.x Resolved ExcelReader time conversion issues by ensuring the same string value used for determining the record field type is the same value used for reading the record value. [nifi]

[via GitHub]

dan-s1 commented on code in PR #9290:
URL: https://github.com/apache/nifi/pull/9290#discussion_r1779160056


##########
nifi-extension-bundles/nifi-poi-bundle/nifi-poi-services/src/main/java/org/apache/nifi/excel/ExcelRecordReader.java:
##########
@@ -127,17 +134,6 @@ private Map<String, Object> getCurrentRowValues(Row 
currentRow, boolean coerceTy
         return currentRowValues;
     }
 
-    private static Object getCellValue(Cell cell) {
-        if (cell != null) {
-            return switch (cell.getCellType()) {
-                case _NONE, BLANK, ERROR, FORMULA, STRING -> 
cell.getStringCellValue();
-                case NUMERIC -> DateUtil.isCellDateFormatted(cell) ? 
cell.getDateCellValue() : cell.getNumericCellValue();
-                case BOOLEAN -> cell.getBooleanCellValue();

Review Comment:
   @exceptionfactory I see the build is failing on the Windows box which has 
the French Locale and in France the separator is a comma and not a period for a 
float number. The stacktrace I see is
   
   ```
   Caused by: java.lang.NumberFormatException: For input string: "18,36"
        at 
java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
        at 
java.base/jdk.internal.math.FloatingDecimal.parseFloat(FloatingDecimal.java:122)
        at java.base/java.lang.Float.parseFloat(Float.java:556)
        at 
org.apache.nifi.serialization.record.util.DataTypeUtils.toFloat(DataTypeUtils.java:1330)
        at 
org.apache.nifi.serialization.record.util.DataTypeUtils.convertType(DataTypeUtils.java:209)
        at 
org.apache.nifi.serialization.record.util.DataTypeUtils.convertType(DataTypeUtils.java:174)
        at 
org.apache.nifi.excel.ExcelRecordReader.convert(ExcelRecordReader.java:134)
        at 
org.apache.nifi.excel.ExcelRecordReader.lambda$getCurrentRowValues$0(ExcelRecordReader.java:119)
        at 
java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104)
        at 
java.base/java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:617)
        at 
org.apache.nifi.excel.ExcelRecordReader.getCurrentRowValues(ExcelRecordReader.java:106)
   ```
   
   Can this be a bug in `DataTypeUtils` which does not take into account the 
`Locale` when parsing a string to a number?
   
   I see on the outside (On a [Google AI 
search](https://www.google.com/search?q=how+in+java+to+parse+floating+number+represented+in+french+with+comma+instead+of+a+period&oq=how+in+java+to+parse+floating+number+represented+in+french+with+comma+instead+of+a+period&gs_lcrp=EgZjaHJvbWUyBggAEEUYOdIBCTI2MjA5ajBqN6gCALACAA&sourceid=chrome&ie=UTF-8#vhid=zephyr:0&vssid=atritem-))
 the following sample code to handle this
          ```
   String frenchNumber = "123,45";
           try {
               NumberFormat nf = NumberFormat.getInstance(Locale.FRANCE);
               double number = nf.parse(frenchNumber).doubleValue();
               System.out.println(number); // Output: 123.45
           } catch (ParseException e) {
               System.out.println("Error parsing number: " + e.getMessage());
           }
   ```



-- 
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: issues-unsubscr...@nifi.apache.org

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