JOOQ Oracle Number precision och java nummer kartläggning

Javas heltalstyper är inte en perfekt matchning för Oracles NUMBER typer. I huvudsak finns det två sätt att kartlägga mellan världarna, båda ofullkomliga:

• Status quo: strikt mindre än NUMBER(3) -> Byte .

  Detta garanterar att ett SQL-värde alltid kan läsas till dess Java-typ. Vissa Java-värden kanske inte går att skriva till SQL-typen.

• Alternativet: Byte -> NUMBER(3) eller mindre.

  Detta kommer att garantera att en Java byte värde kan alltid skrivas till databasen. Vissa DB-värden kanske inte går att läsa i Java-typen.

jOOQ har som standard den första, på grund av följande antaganden:

• jOOQ används mest som ett "database first" API
• de flesta data läses från DB, inte skrivna till DB

Standardbeteende

I jOOQ 3.8.4 är följande logik implementerad 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

Åsidosätter standard

Om du i vissa fall använder NUMBER(3) för att lagra byte nummer upp till 127 till exempel kan du åsidosätta denna standard genom att ange omskrivning av datatyp under kodgenereringsfasen. Detta dokumenteras här:

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