Ticket created : https://issues.apache.org/jira/browse/CAMEL-7742
On Fri, Aug 22, 2014 at 5:25 PM, <[email protected]> wrote: > Well, like I said, I can work with both methods :). > If method B needs more code, then method A can be > the more suitable solution. > > Maybe someone else has another good idea how to implement this feature. > > -----Ursprüngliche Nachricht----- > Gesendet: Thursday, 21 August 2014 um 11:40:31 Uhr > Von: "Charles Moulliard" <[email protected]> > An: [email protected] > Betreff: Re: Re: Re: Camel Bindy: parse a BigDecimal number with a given > pattern > Code should contain tests to verify/validate that and throw exception if > the matching is not perfect. For me the second appraoch with the pattern > will require more code as we have to control the decimal / groupseparator > with what is returned by the Locale ... > > > On Thu, Aug 21, 2014 at 11:29 AM, <[email protected]> wrote: > > > I personally can work with both approaches, but I prefer the pattern > > approach a bit more. > > The reason is that the pattern helps to understand how the numbers looks > > like without seeing the numbers itself. Also I guess it is more > reasonable > > to let DecimalFormat handle the number rather than fixing the number > > manually. > > > > A question for method B is then to use the decimal format symbols coming > > from the current locale and what happens if these chars don't match the > > chars used in the pattern. I guess a ParseException will be thrown? > > > > Thank you for your work so far. > > > > -----Ursprüngliche Nachricht----- > > Gesendet: Thursday, 21 August 2014 um 10:27:04 Uhr > > Von: "Charles Moulliard" <[email protected]> > > An: [email protected] > > Betreff: Re: Re: Camel Bindy: parse a BigDecimal number with a given > > pattern > > Here is what I suggest to implement in Camel Bindy --> > > > > > https://www.dropbox.com/s/vlv3l3icwtowqs2/Screenshot%202014-08-21%2010.23.37.png?dl=0 > > > > There are 2 approaches, one using a Pattern and the other without the > > pattern. Until now, I don't know which one is the best and which one > should > > be favoured ... > > > > > > On Thu, Aug 21, 2014 at 9:32 AM, Charles Moulliard <[email protected]> > > wrote: > > > > > For your information, the "pattern" is not relevant when we use > > > BigDecimalFormat or DoubleFormat. > > > My idea is to propose to add an attribute to specify the groupSeparator > > > and replace the separator by empty string "" > > > > > > Example: We get 123,456,999.00 --> we transform to 125456999.00 before > > to > > > create the BigDecimal > > > > > > Remark : I will have a look as we have also added an attribute > > > "impliedDecimalSeparator" which is used like that when we create the > > > BigDecimal. But I think that it is used for FixLength Format and a > > > different purpose > > > > > > BigDecimal result = new BigDecimal(string.trim()); > > > if (super.hasImpliedDecimalPosition()) { > > > result = result.divide(new > BigDecimal(super.getMultiplier()), > > > super.getPrecision(), RoundingMode.HALF_EVEN); > > > } > > > > > > > > > > > > > > > On Thu, Aug 21, 2014 at 8:33 AM, Charles Moulliard <[email protected]> > > > wrote: > > > > > >> Hi, > > >> > > >> The AbstractNumberFormat class of Bindy used by Double & BigDecimal > uses > > >> the property GroupingUsed(false) but there is no attribute defined > with > > the > > >> @DataField annotation to manage group. Can you raise a ticket please > so > > I > > >> will work on that tomorrow and rediscover the Bindy project that I > > created > > >> some years ago now ;-) ? > > >> > > >> public AbstractNumberFormat(boolean impliedDecimalPosition, int > > >> precision, Locale locale) { > > >> this.impliedDecimalPosition = impliedDecimalPosition; > > >> this.precision = precision > 0 ? precision : 0; > > >> this.format = null; > > >> this.multiplier = 1; > > >> > > >> this.format = new DecimalFormat(); > > >> this.format.setGroupingUsed(false); // SET TO FALSE > > >> > > >> Regards, > > >> > > >> > > >> > > >> > > >> On Wed, Aug 20, 2014 at 8:39 PM, <[email protected]> wrote: > > >> > > >>> The numbers I'd like to parse could have one the following > structures: > > >>> 123,456,789.01 > > >>> 123.45 > > >>> -1234 > > >>> 1,234 > > >>> > > >>> (there are several rows in one file so it is possible that different > > >>> structures appear in a file) > > >>> > > >>> Setting the precision already works fine and the decimal separator is > > >>> treated correctly. > > >>> The current problem is that I can't tell bindy to ignore the comma > > sings > > >>> in every number, > > >>> because they are for grouping purposes and not needed in the > BigDecimal > > >>> field. > > >>> > > >>> If I keep the comma sign in these numbers the parsing process will > > raise > > >>> a NumberFormatException > > >>> mentioning a malformed number. If I remove that comma signs in a test > > >>> file, everything works fine and the number > > >>> is mapped to the datafield correctly, but sadly that can't be a > > >>> solution, because this csv files are provided by > > >>> different system that cannot be changed. > > >>> > > >>> If I use the following annotation > > >>> @DataField(pos = 2, precision = 2, pattern = "#,###.##") > > >>> and use Double instead of BigDecimal I can keep the comma sings. But > I > > >>> can't use Double for several reasons. > > >>> > > >>> The source code of the FormatFactory class (version 2.13.1) that I > > >>> linked in my question also shows that the pattern is used for Double > > types > > >>> (and several other types) but not for BigDecimal types. > > >>> > > >>> -----Ursprüngliche Nachricht----- > > >>> Gesendet: Wednesday, 20 August 2014 um 19:33:05 Uhr > > >>> Von: "Charles Moulliard" <[email protected]> > > >>> An: [email protected] > > >>> Betreff: Re: Camel Bindy: parse a BigDecimal number with a given > > pattern > > >>> The @DataField of Camel bindy proposes the parameter precision like > > also > > >>> a > > >>> pattern but not a grouping separator > > >>> > > >>> Example > > >>> > > >>> @DataField(pos = 2, precision = 2, pattern = "00.00") > > >>> private BigDecimal bigDecimal; > > >>> > > >>> Do you have an example to propose about such use case ? > > >>> > > >>> > > >>> On Wed, Aug 20, 2014 at 3:43 PM, <[email protected]> wrote: > > >>> > > >>> > Hello, > > >>> > > > >>> > I currently have a problem concerning Camel Bindy. I have a csv > file > > >>> that > > >>> > should be parsed with Camel Bindy using a given model class. This > csv > > >>> file > > >>> > contains a number that should be parsed as a BigDecimal. The > problem > > is > > >>> > that > > >>> > this number contains a comma as a grouping separator and a point as > > the > > >>> > decimal separator. > > >>> > If I start the camel route the unmarshal process will throw a > > >>> > NumberFormatException mentioning the invalid format of that number. > > So > > >>> I > > >>> > tried to add a pattern to the DataField annotation, but the error > > >>> stays. > > >>> > > > >>> > After digging throw the documentation ( > > >>> http://camel.apache.org/bindy.html) > > >>> > and the source code of FormatFactory > > >>> > ( > > >>> > > > >>> > > > http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.camel/camel-bindy/2.13.1/org/apache/camel/dataformat/bindy/FormatFactory.java/?v=source > > >>> > ) > > >>> > I'm a little bit confused, because the documentation mentions the > > >>> ability > > >>> > to > > >>> > specify a grouping separator, but the source code shows that the > > >>> pattern is > > >>> > ignored for BigDecimal data types. > > >>> > > > >>> > Does anyone know how to specify that grouping separator? Or is this > > not > > >>> > implemented yet? > > >>> > > > >>> > Many thanks in advance. > > >>> > > > >>> > Best regards. > > >>> > Tom > > >>> > > > >>> > P.S. I also posted that question on stackoverflow > > >>> > ( > > >>> > > > >>> > > > http://stackoverflow.com/questions/25381052/camel-bindy-add-pattern-for-bigdecimal-type > > >>> > ), > > >>> > but with no luck yet. > > >>> > > > >>> > P.P.S. I posted that question using nabble.com ( > > >>> > http://camel.465427.n5.nabble.com/Camel-Users-f465428.html) some > > >>> moments > > >>> > ago, but it seems that there is a problem with my mail provider > that > > >>> > doesn't allow services like this. So I'm sending this question > > directly > > >>> > now. Sorry for any inconveniences. > > >>> > > > >>> > > >>> > > >>> > > >>> -- > > >>> Charles Moulliard > > >>> Apache Committer / Architect @RedHat > > >>> Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > > >>> > > >> > > >> > > >> > > >> -- > > >> Charles Moulliard > > >> Apache Committer / Architect @RedHat > > >> Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > > >> > > >> > > > > > > > > > -- > > > Charles Moulliard > > > Apache Committer / Architect @RedHat > > > Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > > > > > > > > > > > > -- > > Charles Moulliard > > Apache Committer / Architect @RedHat > > Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > > > > > > -- > Charles Moulliard > Apache Committer / Architect @RedHat > Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > -- Charles Moulliard Apache Committer / Architect @RedHat Twitter : @cmoulliard | Blog : http://cmoulliard.github.io
