You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@nifi.apache.org by Mike Thomsen <mi...@gmail.com> on 2019/05/28 14:59:19 UTC

Would a currency parser record path function be useful?

We have a controller service that does some basic cleanup on currency to
take a string and turn it into a float or double. It's not intended to be
anything like the Java Money API, it just purges everything except raw
currency-related characters and formats the text into a float or double.

Would that be a helpful addition to the standard record path? I would
imagine something like this:

toCurrencyString(parseRawCurrency("USD100000.0"), "US")

= $100,00.00

So the first function would just try to clean the string down to a bare
double and the next one could use NumberFormats and Locales to give you a
clean currency string.

I looked into the Java Money API before proposing this, and it seems like
it might be overkill and not even that helpful since converting currencies
is largely useless without an accurate conversion rate data source.

Thoughts?

Re: Would a currency parser record path function be useful?

Posted by Andrew Grande <ap...@gmail.com>.
Honestly, I have seen so many unique ways to mangle the currency format,
that I'm not even sure one can reliably parse one anymore.

But more importantly, isn't it the responsibility of a representation layer
to format and pretty print the value? Just have hard time seeing a
widespread need for that within NiFi itself.

This is just me sharing my experiences, not to discourage you from
contributing :)

Andrew

On Tue, May 28, 2019, 7:59 AM Mike Thomsen <mi...@gmail.com> wrote:

> We have a controller service that does some basic cleanup on currency to
> take a string and turn it into a float or double. It's not intended to be
> anything like the Java Money API, it just purges everything except raw
> currency-related characters and formats the text into a float or double.
>
> Would that be a helpful addition to the standard record path? I would
> imagine something like this:
>
> toCurrencyString(parseRawCurrency("USD100000.0"), "US")
>
> = $100,00.00
>
> So the first function would just try to clean the string down to a bare
> double and the next one could use NumberFormats and Locales to give you a
> clean currency string.
>
> I looked into the Java Money API before proposing this, and it seems like
> it might be overkill and not even that helpful since converting currencies
> is largely useless without an accurate conversion rate data source.
>
> Thoughts?
>