Incorrect information when loading bigdecimal entity

3

I have a table, that one of its columns is a numeric (25,10) that will be shown rates. But there are records that will be reset (0.0000000000)

In my entity you have ownership of this fee, such as a BigDecimal . But when hibernate populates this property, it assigns the value "0E-10" inves of 0.0000000000. I have tried precision or Scale , but I did not find the solution.

@DecimalMin("0.0")
@Digits(integer = 25, fraction = 10)
@Field(at = 8, required = true)
@Column(name = TableConstants.Columns.TAXA_OPERACAO)
private BigDecimal taxaOperacao;

    
asked by anonymous 04.08.2015 / 22:28

1 answer

2

Nothing is wrong. It happens that the 0.0000000000 is being represented by the scientific notation when viewed by the debug.

Anyway,thiswillnotcauseanyerrors,sinceit'sjustarepresentation.Youraccountswillbemadewith0.

UPDATE-Completedtheanswer:

IwascuriousthatforsomecasestheBigDecimaltoString()printsinscientificnotation,forothercasesitdoesnot.Icheckedthesourcecodeand,ascanbeseeninthecodesnippetbelow,thedecisionismadebasedonthenumberstored.

Themethodbelow,layoutChars,iscalledbytoString()bypassingtruetothesciparameter.Thesciparametermeanstoprintinscientificnotation.Ifitisfalse,thenthenumberisprintedintheengineeringnotation.

Notethatitdependsonsomeconditionsforthenumbertobeprintedinscientificnotation,thescale,adjustedvariableandthesciresponsibleforthis.

3051  private String layoutChars(boolean sci) {
3052 if (scale == 0) // zero scale is trivial
3053 return (intCompact != INFLATED) ?
3054 Long.toString(intCompact):
3055 intVal.toString();
3057 // Get the significand as an absolute value
3058 char coeff[];
3059 if (intCompact != INFLATED)
3060 coeff = Long.toString(Math.abs(intCompact)).toCharArray();
3061 else
3062 coeff = intVal.abs().toString().toCharArray();
3064 // Construct a buffer, with sufficient capacity for all cases.
3065 // If E-notation is needed, length will be: +1 if negative, +1
3066 // if '.' needed, +2 for "E+", + up to 10 for adjusted exponent.
3067 // Otherwise it could have +1 if negative, plus leading "0.00000"
3068 StringBuilder buf=new StringBuilder(coeff.length+14);
3069 if (signum() < 0) // prefix '-' if negative
3070 buf.append('-');
3071 long adjusted = -(long)scale + (coeff.length-1);
3072 if ((scale >= 0) && (adjusted >= -6)) { // plain number
3073 int pad = scale - coeff.length; // count of padding zeros
3074 if (pad >= 0) { // 0.xxx form
3075 buf.append('0');
3076 buf.append('.');
3077 for (; pad>0; pad--) {
3078 buf.append('0');
3079 }
3080 buf.append(coeff);
3081 } else { // xx.xx form
3082 buf.append(coeff, 0, -pad);
3083 buf.append('.');
3084 buf.append(coeff, -pad, scale);
3085 }
3086 } else { // E-notation is needed
3087 if (sci) { // Scientific notation
3088 buf.append(coeff[0]); // first character
3089 if (coeff.length > 1) { // more to come
3090 buf.append('.');
3091 buf.append(coeff, 1, coeff.length-1);
3092 }
3093 } else { // Engineering notation
3094 int sig = (int)(adjusted % 3);
3095 if (sig < 0)
3096 sig += 3; // [adjusted was negative]
3097 adjusted -= sig; // now a multiple of 3
3098 sig++;
3099 if (signum() == 0) {
3100 switch (sig) {
3101 case 1:
3102 buf.append('0'); // exponent is a multiple of three
3103 break;
3104 case 2:
3105 buf.append("0.00");
3106 adjusted += 3;
3107 break;
3108 case 3:
3109 buf.append("0.0");
3110 adjusted += 3;
3111 break;
3112 default:
3113 throw new AssertionError("Unexpected sig value " + sig);
3114 }
3115 } else if (sig >= coeff.length) { // significand all in integer
3116 buf.append(coeff, 0, coeff.length);
3117 // may need some zeros, too
3118 for (int i = sig - coeff.length; i > 0; i--)
3119 buf.append('0');
3120 } else { // xx.xxE form
3121 buf.append(coeff, 0, sig);
3122 buf.append('.');
3123 buf.append(coeff, sig, coeff.length-sig);
3124 }
3125 }
3126 if (adjusted != 0) { // [!sci could have made 0]
3127 buf.append('E');
3128 if (adjusted > 0) // force sign for positive
3129 buf.append('+');
3130 buf.append(adjusted);
3131 }
3132 }
3133 return buf.toString();
3134 }

Finally, the Java debug shown in the question image is calling toString () and the stored number, 0.0000000000, causes the print to be in scientific notation.

This code snippet has been extracted from: link

    
04.08.2015 / 23:14