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:
http://www.jooq.org/doc /latest/manual/code-generation/data-type-rewrites