tl;dr
myPreparedStatement.setObject(
… ,
java.util.UUID.randomUUID()
)
Detaljer
(a) Vis os din kode.
PreparedStatement::setObject virker, når du sender en java.util.UUID . Du har sandsynligvis et andet problem i din kode.
(b) Se mit blogindlæg UUID-værdier fra JDBC til Postgres for lidt diskussion og eksempelkode.
// 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) Jeg er ikke sikker på, hvad du mener med
De seneste Java JDBC-drivere til postgres hævder at understøtte UUID'er indbygget
Hvilken driver? Der er mindst to open source JDBC-drivere til Postgres, den nuværende/legacy og en ny omskrivning "næste generation". Og der er også andre kommercielle chauffører.
"indfødt"? Kan du linke til den dokumentation, du læser? SQL-specifikationen har ingen datatype for UUID (desværre ☹), derfor har JDBC-specifikationen ingen datatype for UUID. Som en løsning bruger JDBC-driveren til Postgres setObject og getObject metoder på PreparedStatement flytter UUID på tværs af kløften mellem Java ↔ SQL ↔ Postgres. Se eksempelkoden ovenfor.
Som PreparedStatement JDBC doc siger:
Hvis der kræves vilkårlige parametertypekonverteringer, skal metoden setObject bruges med en SQL-måltype.
Måske med "natively" forvekslede du Postgres' oprindelige understøttelse af UUID som en datatype med JDBC med en UUID-datatype. Postgres understøtter faktisk UUID som en datatype, hvilket betyder, at værdien gemmes som 128-bit i stedet for flere gange, hvis den blev gemt som ASCII- eller Unicode-hex-streng. Og at være indfødt betyder også, at Postgres ved, hvordan man bygger et indeks på en kolonne af den type.
Pointen med mit blogindlæg nævnt ovenfor var, at jeg blev glædeligt overrasket over, hvor nemt det er at bygge bro mellem Java ↔ SQL ↔ Postgres . I mine første uuddannede forsøg arbejdede jeg for hårdt.
En anden note om Postgres, der understøtter UUID... Postgres ved, hvordan man gemmer, indekserer og henter eksisterende UUID-værdier. At generere UUID-værdier, skal du aktivere Postgres-udvidelsen (plugin) uuid-ossp . Denne udvidelse omslutter et bibliotek leveret af OSSP Project til generering af en række forskellige slags UUID-værdier. Se min blog for instruktioner.
Forresten...
Hvis jeg vidste, hvordan jeg skulle anmode JDBC-ekspertgruppen eller JSR-teamet om at gøre JDBC opmærksom på UUID, ville jeg bestemt gøre det. De gør netop det for de nye dato- og klokkeslætstyper, der er defineret i JSR 310:Date and Time API.
På samme måde, hvis jeg vidste, hvordan jeg skulle anmode SQL-standardudvalget om at tilføje en datatype UUID, ville jeg. Men tilsyneladende er den komité mere hemmelighedsfuld end det sovjetiske politbureau og langsommere end en gletsjer.