JOOQ Oracle Number precision и java числово картографиране

Целочислените типове на Java не съвпадат перфектно с NUMBER на Oracle видове. По същество има два начина за картографиране между световете, и двата несъвършени:

• Статуквото: строго по-малко от NUMBER(3) -> Byte .

  Това гарантира, че дадена SQL стойност винаги може да бъде прочетена в нейния тип Java. Някои стойности на Java може да не могат да се записват в типа SQL.

• Алтернативата: Byte -> NUMBER(3) или по-малко.

  Това ще гарантира, че Java byte стойността винаги може да бъде записана в базата данни. Някои DB стойности обаче може да не могат да бъдат прочетени в типа Java.

jOOQ по подразбиране е първият, поради следните предположения:

• jOOQ се използва най-вече като API „първо за базата данни“
• повечето от данните се четат от DB, а не се записват в DB

Поведението по подразбиране

В jOOQ 3.8.4 следната логика е внедрена в DefaultDataType.getNumericClass() :

// Integers
if (scale == 0 && precision != 0) {
    if (precision < BYTE_PRECISION) {
        return Byte.class;
    }
    if (precision < SHORT_PRECISION) {
        return Short.class;
    }
    if (precision < INTEGER_PRECISION) {
        return Integer.class;
    }
    if (precision < LONG_PRECISION) {
        return Long.class;
    }

    // Default integer number
    return BigInteger.class;
}

// Non-integers
else {
    return BigDecimal.class;
}

С:

int LONG_PRECISION    = String.valueOf(Long.MAX_VALUE).length();    // 19
int INTEGER_PRECISION = String.valueOf(Integer.MAX_VALUE).length(); // 10
int SHORT_PRECISION   = String.valueOf(Short.MAX_VALUE).length();   // 5
int BYTE_PRECISION    = String.valueOf(Byte.MAX_VALUE).length();    // 3

Замяна на стандартното

Ако в някои случаи използвате NUMBER(3) за съхраняване на byte числа до 127 например, можете да замените това по подразбиране, като посочите пренаписване на типа данни по време на фазата на генериране на код. Това е документирано тук:

http://www.jooq.org/doc /latest/manual/code-generation/data-type-rewrites