JOOQ Dokładność liczb Oracle i mapowanie liczb w języku Java

Typy całkowite w Javie nie pasują idealnie do NUMBER Oracle typy. Zasadniczo istnieją dwa sposoby mapowania między światami, oba niedoskonałe:

• Status quo: ściśle mniej niż NUMBER(3) -> Byte .

  Gwarantuje to, że wartość SQL można zawsze odczytać w jej typie Java.Niektóre wartości Java mogą nie być zapisywalne w typie SQL.

• Alternatywa: Byte -> NUMBER(3) lub mniej.

  Gwarantuje to, że byte Java wartość zawsze można zapisać do bazy danych. Niektóre wartości DB mogą jednak nie być odczytywane przez typ Java.

jOOQ domyślnie wybiera pierwszy, ze względu na następujące założenia:

• jOOQ jest najczęściej używany jako API „najpierw baza danych”
• Większość danych jest odczytywana z bazy danych, a nie zapisywana do bazy danych

Domyślne zachowanie

W jOOQ 3.8.4 następująca logika jest zaimplementowana w 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;
}

Z:

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

Zastępowanie ustawienia domyślnego

Jeśli w niektórych przypadkach używasz NUMBER(3) do przechowywania byte numery do 127 na przykład możesz zastąpić to ustawienie domyślne, określając przepisywanie typu danych podczas fazy generowania kodu. Jest to udokumentowane tutaj:

http://www.jooq.org/doc /latest/manual/generowanie-kodu/przepisywanie-typów-danych