JOOQ Oracle Number præcision og java nummer mapping

Javas heltalstyper passer ikke perfekt til Oracles NUMBER typer. Grundlæggende er der to måder at kortlægge mellem verdenerne på, begge ufuldkomne:

Status quo: strengt taget mindre end NUMBER(3) -> Byte .

Dette garanterer, at en SQL-værdi altid kan læses til dens Java-type. Nogle Java-værdier kan muligvis ikke skrives til SQL-typen.
Alternativet: Byte -> NUMBER(3) eller mindre.

Dette vil garantere, at en Java byte værdi kan altid skrives til databasen. Nogle DB-værdier kan dog muligvis ikke læses i Java-typen.

jOOQ er som standard den første på grund af følgende antagelser:

jOOQ bruges mest som en "database først" API
de fleste data læses fra DB, ikke skrevet til DB

Standardadfærd

I jOOQ 3.8.4 er følgende logik implementeret i 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;
}

Med:

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

Tilsidesættelse af standarden

Hvis du i nogle tilfælde bruger NUMBER(3) for at gemme byte numre op til 127 for eksempel kan du tilsidesætte denne standard ved at angive datatypeomskrivning under kodegenereringsfasen. Dette er dokumenteret her:

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