JPA automatique BigDecimal de conversion

Nous sommes la génération de nos jpa accès couches avec MyEclipse. Ensuite, nous avons généré des modèles de données et de la couche d'accès aux services. Nous avons rencontré quelques problèmes pour certains champs avec une précision définie.

Entité:

@Entity
public class TestEntity{
   @Column(name="DECTEST", scale = 3, precision = 13)
   BigDecimal decTest;

}

Maintenant nous allons créer un haricot et essayer de la sauver:

TestEntity te = new TestEntity();
te.setDecTest(new BigDecimal(1.2));

TestEntityService.save(te);

Nous obtenons le message d'erreur suivant:
Causés par: com.ibm.db2.ccc.c.SqlException: [ibm][db2][ccc][t4][1037][11190] Exception s'est produite lors de BigDecimal de conversion. Voir ci-joint Throwable pour plus de détails.

Caused by: com.ibm.db2.jcc.a.a: [ibm][db2][jcc][converters][608][10994] Overflow occurred during numeric data type conversion of "1.1999999999999999555910790149937383830547332763671875".
at com.ibm.db2.jcc.a.e.a(e.java:61)
at com.ibm.db2.jcc.b.jb.a(jb.java:1772)
... 73 more

Le problème semble être que notre BigDecimals échelle est supérieur à celui de la base de données.

Un travail solution de contournement est:

TestEntity te = new TestEntity();

BigDecimal decTest = new BigDecimal(1.2);

te.setDecTest(decTest.setScale(3,RoundingMode.HALF_UP);

TestEntityService.save(te);

Avec cette solution de contournement, nous devons réduire le BigDecimals precicsion manuellement à celui de la base de données.

Toutefois, si le modèle de données des changements, il nous faudrait ajuster l'échelle, il y manuellement. Est-il un moyen d'obtenir notre jpa /hibernate mise en œuvre pour faire la conversion pour nous automatiquement? E. g. avec la définition d'une propriété. Le faire à l'endroit où l'on est de la création de la fève serait le mauvais endroit pour le faire de toute façon.

OriginalL'auteur Udo Held | 2012-08-10

  1. 7

    Vous pourriez utiliser un type d'utilisateur, ou vous pouvez simplement mettre en œuvre le setter de la propriété comme cela:

    public void setDecTest(BigDecimal decTest) {
    this.decTest = decTest.setScale(3, RoundingMode.HALF_UP));
}

    Cet arrondissement serait donc encapsulé dans l'entité.

    Noter que l'utilisation d'un lit double pour initialiser un BigDecimal est un peu étrange. Si vous voulez 1.2 être stockés dans la BigDecimal, utilisez new BigDecimal("1.2"), et vous n'aurez pas un BigDecimal initialisé avec 1.1999999999999999555910790149937383830547332763671875.

    Pensée au sujet de ces deux ainsi. Cependant, le 1.2 a des fins de test. Son entrée à partir de l'INTERFACE utilisateur et doivent être validées dans un certain nombre de sorte que personne ne peut envoyer vers le bas "bonjour" au lieu d'un nombre. Comme la couche d'accès est généré je ne veux pas le modifier. À l'aide de plusieurs BigDecimal propriétés de la méthode manuelle n'est pas agréable, mais si rien de mieux se lève, nous avons probablement aller pour elle.
    Vous m'avez sauvé quelques soucis avec votre commentaire à propos de ne pas l'analyse en double pour le constructeur de BigDecimal. c'était une tentation que j'avais besoin de dire non.

    OriginalL'auteur JB Nizet