tl;dr
myPreparedStatement.setObject(
… ,
java.util.UUID.randomUUID()
)
Details
(a) Laat ons uw code zien.
PreparedStatement::setObject werkt wel bij het doorgeven van een java.util.UUID . Je hebt waarschijnlijk een ander probleem in je code.
(b) Zie mijn blogbericht UUID Values From JDBC to Postgres voor een beetje discussie en voorbeeldcode.
// 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) Ik weet niet zeker wat je bedoelt met
De nieuwste Java JDBC-stuurprogramma's voor postgres beweren native UUID's te ondersteunen
Welke chauffeur? Er zijn ten minste twee open-source JDBC-stuurprogramma's voor Postgres, de huidige/legacy en een nieuwe "next generation" herschreven versie. En er zijn ook andere commerciële coureurs.
"inheems"? Kun je linken naar de documentatie die je hebt gelezen? De SQL-specificatie heeft geen gegevenstype voor UUID (helaas ☹), daarom heeft de JDBC-specificatie geen gegevenstype voor UUID. Als tijdelijke oplossing gebruikt het JDBC-stuurprogramma voor Postgres het setObject en getObject methoden op PreparedStatement verplaatsen de UUID over de kloof tussen Java ↔ SQL ↔ Postgres. Zie de voorbeeldcode hierboven.
Zoals het PreparedStatement JDBC-document zegt:
Als willekeurige conversies van parametertypes vereist zijn, moet de methode setObject worden gebruikt met een doel-SQL-type.
Misschien door "native", verwarde u de native ondersteuning van Postgres voor UUID als een gegevenstype met JDBC met een UUID-gegevenstype. Postgres ondersteunt inderdaad UUID als een gegevenstype, wat betekent dat de waarde wordt opgeslagen als 128-bits in plaats van meerdere keren dat als deze zou zijn opgeslagen als ASCII- of Unicode hex-tekenreeks. En native zijn betekent ook dat Postgres weet hoe een index op een kolom van dat type moet worden gebouwd.
Het punt van mijn hierboven genoemde blogpost was dat ik aangenaam verrast was door hoe eenvoudig het is om die kloof tussen Java ↔ SQL ↔ Postgres te overbruggen. . Bij mijn eerste ongeschoolde pogingen werkte ik te hard.
Nog een opmerking over Postgres die UUID ondersteunt... Postgres weet hoe bestaande UUID-waarden moeten worden opgeslagen, geïndexeerd en opgehaald. Om te genereren UUID-waarden, moet u de Postgres-extensie (plug-in) uuid-ossp inschakelen . Deze extensie omhult een bibliotheek die wordt geleverd door The OSSP Project voor het genereren van verschillende soorten UUID-waarden. Zie mijn blog voor instructies.
Trouwens...
Als ik wist hoe ik een verzoekschrift moest indienen bij de JDBC-expertgroep of het JSR-team om JDBC op de hoogte te stellen van UUID, zou ik dat zeker doen. Ze doen precies dat voor de nieuwe datum-tijd-typen die worden gedefinieerd in JSR 310:Date and Time API.
Evenzo, als ik wist hoe ik de SQL-standaardcommissie moest verzoeken om een gegevenstype van UUID toe te voegen, zou ik dat doen. Maar blijkbaar is die commissie geheimzinniger dan het Sovjet Politburo en langzamer dan een gletsjer.