Mike,
Thanks for your suggestions. I plan to add this to the additionalDetails
as you suggested. I think the main problem though is the user specified
this field to be of type string in their schema hence even if there is a
setting to output non-scientific notation it will not help as the setting
only helps for numbers. I see this to be true as I have another
ConvertRecord configured with an ExcelReader and a JsonRecordSetWriter
configured with property "Allow Scientific Notation" to be false and I
still get the scientific notation as seen below
[ {
"ID" : 2,
"Name" : "Person 2",
"Phone" : "9.87654321E9"
} ]
On Fri, May 2, 2025 at 1:42 PM Michael Moser <moser...@gmail.com> wrote:
> 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?
> >
>
