Die Integer-Typen von Java passen nicht perfekt zu Oracles NUMBER Typen. Im Wesentlichen gibt es zwei Möglichkeiten, zwischen den Welten abzubilden, beide unvollkommen:
-
Der Status quo: streng kleiner als
NUMBER(3)->Byte.Dies garantiert, dass ein SQL-Wert immer in seinen Java-Typ gelesen werden kann. Einige Java-Werte können möglicherweise nicht in den SQL-Typ geschrieben werden.
-
Die Alternative:
Byte->NUMBER(3)oder weniger.Dadurch wird garantiert, dass ein Java
byteWert kann immer in die Datenbank geschrieben werden. Einige DB-Werte sind jedoch möglicherweise nicht in den Java-Typ lesbar.
jOOQ verwendet aufgrund der folgenden Annahmen standardmäßig die erste:
- jOOQ wird meistens als "Database First"-API verwendet
- Die meisten Daten werden aus der DB gelesen, nicht in die DB geschrieben
Das Standardverhalten
In jOOQ 3.8.4 ist die folgende Logik implementiert 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;
}
Mit:
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
Standardeinstellung überschreiben
Wenn Sie in einigen Fällen NUMBER(3) verwenden um byte zu speichern Nummern bis 127 Beispielsweise können Sie diese Standardeinstellung überschreiben, indem Sie während der Codegenerierungsphase das Umschreiben des Datentyps angeben. Dies ist hier dokumentiert:
http://www.jooq.org/doc /latest/manual/code-generation/data-type-rewrites
