tl;dr
myPreparedStatement.setObject(
… ,
java.util.UUID.randomUUID()
)
Detalhes
(a) Mostre-nos o seu código.
PreparedStatement::setObject funciona ao passar um java.util.UUID . Você provavelmente tem algum outro problema no seu código. (b) Veja minha postagem no blog UUID Values From JDBC to Postgres para um pouco de discussão e código de exemplo.
// 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) Não tenho certeza do que você quer dizer com
Os drivers Java JDBC mais recentes para postgres afirmam oferecer suporte nativo a UUIDs
Qual motorista? Existem pelo menos dois drivers JDBC de código aberto para o Postgres, o atual/legado e um novo reescrito de "próxima geração". E há outros motoristas comerciais também.
"nativamente"? Você pode linkar para a documentação que você leu? A especificação SQL não possui tipo de dados para UUID (infelizmente ☹), portanto a especificação JDBC não possui tipo de dados para UUID. Como solução alternativa, o driver JDBC para Postgres usa o
setObject e getObject métodos em PreparedStatement movem o UUID através do abismo entre Java ↔ SQL ↔ Postgres. Veja o código de exemplo acima. Como o documento JDBC PreparedStatement diz:
Se forem necessárias conversões de tipo de parâmetro arbitrário, o método setObject deve ser usado com um tipo de SQL de destino.
Talvez por "nativamente", você confundiu o suporte nativo do Postgres para UUID como um tipo de dados com JDBC tendo um tipo de dados UUID. O Postgres realmente suporta UUID como um tipo de dados, o que significa que o valor é armazenado como 128 bits em vez de várias vezes se fosse armazenado como uma string hexadecimal ASCII ou Unicode. E ser nativo também significa que o Postgres sabe como construir um índice em uma coluna desse tipo.
O ponto da minha postagem no blog mencionado acima foi que fiquei agradavelmente surpreso com o quão simples é preencher esse abismo entre
Java ↔ SQL ↔ Postgres . Nas minhas primeiras tentativas sem educação, eu estava trabalhando demais. Outra observação sobre o suporte do Postgres ao UUID… O Postgres sabe como armazenar, indexar e recuperar valores de UUID existentes. Para gerar Valores UUID, você deve habilitar a extensão Postgres (plugin)
uuid-ossp . Esta extensão envolve uma biblioteca fornecida pelo The OSSP Project para gerar uma variedade de tipos de valores UUID. Veja meu blog para instruções. A propósito…
Se eu soubesse como fazer uma petição ao grupo de especialistas do JDBC ou à equipe do JSR para conscientizar o JDBC sobre o UUID, certamente o faria. Eles estão fazendo exatamente isso para os novos tipos de data e hora que estão sendo definidos no JSR 310:API de data e hora.
Da mesma forma, se eu soubesse como fazer uma petição ao comitê de padrões SQL para adicionar um tipo de dados UUID, eu o faria. Mas aparentemente esse comitê é mais secreto que o Politburo soviético e mais lento que uma geleira.
