tl;dr
myPreparedStatement.setObject(
… ,
java.util.UUID.randomUUID()
)
Dettagli
(a) Mostraci il tuo codice.
PreparedStatement::setObject funziona quando si passa un java.util.UUID . Probabilmente hai qualche altro problema nel tuo codice.
(b) Vedi il mio post sul blog Valori UUID Da JDBC a Postgres per un po' di discussione e codice di esempio.
// Generate or obtain data to store in database.
java.util.UUID uuid = java.util.UUID.randomUUID(); // Generate a random UUID.
String foodName = "Croissant";
// JDBC Prepared Statement.
PreparedStatement preparedStatement = conn.prepareStatement( "INSERT INTO food_ (pkey_, food_name_ ) VALUES (?,?)" );
int nthPlaceholder = 1; // 1-based counting (not an index).
preparedStatement.setObject( nthPlaceholder++, uuid );
preparedStatement.setString( nthPlaceholder++, foodName );
// Execute SQL.
if ( !( preparedStatement.executeUpdate() == 1 ) ) {
// If the SQL reports other than one row inserted…
this.logger.error( "Failed to insert row into database." );
}
(c) Non sono sicuro di cosa intendi con
Gli ultimi driver JDBC Java per postgres affermano di supportare gli UUID in modo nativo
Quale pilota? Ci sono almeno due driver JDBC open source per Postgres, quello attuale/legacy e uno nuovo di "prossima generazione". E ci sono anche altri driver commerciali.
"nativo"? Puoi linkare la documentazione che hai letto? La specifica SQL non ha un tipo di dati per l'UUID (purtroppo ☹), quindi la specifica JDBC non ha un tipo di dati per l'UUID. Come soluzione alternativa, il driver JDBC per Postgres utilizza setObject e getObject i metodi su PreparedStatement spostano l'UUID attraverso il baratro tra Java ↔ SQL ↔ Postgres. Vedi il codice di esempio sopra.
Come dice il documento JDBC PreparedStatement:
Se sono necessarie conversioni arbitrarie del tipo di parametro, il metodo setObject deve essere utilizzato con un tipo SQL di destinazione.
Forse "nativamente", hai confuso il supporto nativo di Postgres per UUID come tipo di dati con JDBC che ha un tipo di dati UUID. Postgres supporta effettivamente UUID come tipo di dati, il che significa che il valore viene archiviato come 128 bit anziché più volte che se fosse archiviato come stringa esadecimale ASCII o Unicode. Ed essere nativo significa anche che Postgres sa come costruire un indice su una colonna di quel tipo.
Il punto del mio post sul blog sopra menzionato è che sono rimasto piacevolmente sorpreso da quanto sia semplice colmare l'abisso tra Java ↔ SQL ↔ Postgres . Nei miei primi tentativi ignoranti, stavo lavorando troppo.
Un'altra nota su Postgres che supporta UUID... Postgres sa come memorizzare, indicizzare e recuperare valori UUID esistenti. Per generare valori UUID, devi abilitare l'estensione Postgres (plugin) uuid-ossp . Questa estensione racchiude una libreria fornita da The OSSP Project per generare una varietà di tipi di valori UUID. Vedi il mio blog per le istruzioni.
A proposito...
Se sapessi come presentare una petizione al gruppo di esperti JDBC o al team JSR per rendere JDBC consapevole dell'UUID, lo farei sicuramente. Stanno facendo proprio questo per i nuovi tipi di data e ora definiti in JSR 310:API Date and Time.
Allo stesso modo, se sapessi come presentare una petizione al comitato per gli standard SQL per aggiungere un tipo di dati di UUID, lo farei. Ma a quanto pare quel comitato è più riservato del Politburo sovietico e più lento di un ghiacciaio.
