Java's integer-types komen niet perfect overeen met Oracle's NUMBER
soorten. In wezen zijn er twee manieren om de werelden in kaart te brengen, beide onvolmaakt:
-
De status-quo: strikt kleiner dan
NUMBER(3)
->Byte
.Dit garandeert dat een SQL-waarde altijd kan worden gelezen naar het Java-type. Sommige Java-waarden zijn mogelijk niet schrijfbaar naar het SQL-type.
-
Het alternatief:
Byte
->NUMBER(3)
of minder.Dit garandeert dat een Java
byte
waarde kan altijd naar de database worden geschreven. Sommige DB-waarden zijn echter mogelijk niet leesbaar in het Java-type.
jOOQ gebruikt standaard de eerste, vanwege de volgende aannames:
- jOOQ wordt meestal gebruikt als een "database first" API
- de meeste gegevens worden uit de DB gelezen, niet naar de DB geschreven
Het standaardgedrag
In jOOQ 3.8.4 is de volgende logica geïmplementeerd in 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;
}
Met:
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
De standaard overschrijven
Als u in sommige gevallen NUMBER(3)
. gebruikt om byte
op te slaan cijfers tot 127
u kunt deze standaard bijvoorbeeld overschrijven door het herschrijven van het gegevenstype tijdens de codegeneratiefase op te geven. Dit is hier gedocumenteerd:
http://www.jooq.org/doc /latest/manual/code-generation/data-type-rewrites