tl;dr
myPreparedStatement.setObject(
… ,
java.util.UUID.randomUUID()
)
Detaljer
(a) Visa oss din kod.
PreparedStatement::setObject fungerar när du skickar en java.util.UUID . Du har förmodligen något annat problem med din kod.
(b) Se mitt blogginlägg UUID-värden från JDBC till Postgres för lite diskussion och exempelkod.
// 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) Jag är inte säker på vad du menar med
De senaste Java JDBC-drivrutinerna för postgres hävdar att de stöder UUID inbyggt
Vilken förare? Det finns minst två JDBC-drivrutiner med öppen källkod för Postgres, den nuvarande/legacy och en ny omskrivning "nästa generation". Och det finns andra kommersiella förare också.
"infödd"? Kan du länka till dokumentationen du läst? SQL-specifikationen har ingen datatyp för UUID (tyvärr ☹), därför har JDBC-specifikationen ingen datatyp för UUID. Som en lösning använder JDBC-drivrutinen för Postgres setObject och getObject metoder på PreparedStatement flyttar UUID över avgrunden mellan Java ↔ SQL ↔ Postgres. Se exempelkoden ovan.
Som PreparedStatement JDBC doc säger:
Om godtyckliga parametertypkonverteringar krävs, ska metoden setObject användas med en mål-SQL-typ.
Du kanske genom "natively" förväxlade Postgres inbyggda stöd för UUID som en datatyp med JDBC som har en UUID-datatyp. Postgres stöder verkligen UUID som en datatyp, vilket innebär att värdet lagras som 128-bitar snarare än flera gånger som om det lagrades som ASCII eller Unicode hex-sträng. Och att vara infödd betyder också att Postgres vet hur man bygger ett index på en kolumn av den typen.
Poängen med mitt blogginlägg som nämndes ovan var att jag blev positivt överraskad över hur enkelt det är att överbrygga den avgrunden mellan Java ↔ SQL ↔ Postgres . I mina första outbildade försök arbetade jag för hårt.
En annan anteckning om att Postgres stöder UUID... Postgres vet hur man lagrar, indexerar och hämtar befintliga UUID-värden. Att generera UUID-värden, du måste aktivera Postgres-tillägget (plugin) uuid-ossp . Denna tillägg omsluter ett bibliotek som tillhandahålls av OSSP Project för att generera en mängd olika typer av UUID-värden. Se min blogg för instruktioner.
Förresten...
Om jag visste hur jag skulle göra en petition till JDBC-expertgruppen eller JSR-teamet för att göra JDBC medveten om UUID, skulle jag verkligen göra det. De gör just det för de nya datum-tid-typerna som definieras i JSR 310:Date and Time API.
På samma sätt, om jag visste hur jag skulle begära att SQL-standardkommittén skulle lägga till en datatyp av UUID, skulle jag göra det. Men uppenbarligen är den kommittén mer hemlig än den sovjetiska politbyrån och långsammare än en glaciär.