I tipi interi di Java non corrispondono perfettamente a NUMBER
di Oracle tipi. In sostanza, ci sono due modi per mappare tra i mondi, entrambi imperfetti:
-
Lo status quo: rigorosamente inferiore a
NUMBER(3)
->Byte
.Ciò garantisce che un valore SQL possa sempre essere letto nel suo tipo Java.Alcuni valori Java potrebbero non essere scrivibili nel tipo SQL.
-
L'alternativa:
Byte
->NUMBER(3)
o meno.Ciò garantirà che un Java
byte
il valore può sempre essere scritto nel database. Tuttavia, alcuni valori DB potrebbero non essere leggibili nel tipo Java.
jOOQ per impostazione predefinita è il primo, a causa dei seguenti presupposti:
- jOOQ è usato principalmente come API "database first"
- La maggior parte dei dati viene letta dal DB, non scritta nel DB
Il comportamento predefinito
In jOOQ 3.8.4, la seguente logica è implementata 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;
}
Con:
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
Sostituzione dell'impostazione predefinita
Se in alcuni casi utilizzi NUMBER(3)
per memorizzare byte
numeri fino a 127
ad esempio, puoi ignorare questa impostazione predefinita specificando la riscrittura del tipo di dati durante la fase di generazione del codice. Questo è documentato qui:
http://www.jooq.org/doc /latest/manual/code-generation/data-type-rewrites