Hi Dan,
I would put information like that in the ExcelReader Additional Details
section. It appears there is an existing "Schemas and Type Coercion"
section, so that seems like a good place to explain this case as concisely
as possible.
That said, there was some work done for NIFI-12697 to allow
JsonRecordSetWriter to output non-scientific notation. Perhaps something
can be done in CsvRecordSetWriter that can do something similar.
-- Mike
On Fri, May 2, 2025 at 11:57 AM Dan S <dsti...@gmail.com> wrote:
> I recently had a user reach out to me with something which appeared as a
> bug but I believe is not.
> The user had a ConvertRecord processor configured with a ExcelReader and a
> CSVRecordSetWriter.
> Their Excel workbook had a sheet with columns with large long numbers (in
> his example they were 10 digit phone numbers). The user specified in a
> schema
> that this column was a string. E.g.
>
>
> {"type":"record","name":"nifiRecord","namespace":"org.apache.nifi","fields":[{"name":"ID","type":["long","null"]},{"name":"Name","type":["string","null"]},{"name":"Phone","type":["string","null"]}]}
>
> As a result instead of a long being outputted a number with scientific
> notation was outputted.
>
> E.g. for the number 9876543210 the output was 9.87654321E9
>
> I believe this is not a bug since Excel stores all numbers as doubles and
> POI returns a double when retrieving the value (as seen when debugging).
> When calling a toString on a Java Double then a number in scientific
> notation is produced.
>
> I was wondering where documentation for this type of tidbit (i.e. Excel
> stores all numbers as a double) go?
>
