Postgres UUID JDBC nie działa

tl;dr

myPreparedStatement.setObject( 
    … , 
    java.util.UUID.randomUUID()
)

Szczegóły

(a) Pokaż nam swój kod.

PreparedStatement::setObject działa podczas przekazywania java.util.UUID . Prawdopodobnie masz inny problem w swoim kodzie.

(b) Zobacz mój wpis na blogu Wartości UUID z JDBC do Postgres, aby zapoznać się z krótką dyskusją i przykładowym kodem.

// 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." );
}

Najnowsze sterowniki Java JDBC dla postgres twierdzą, że natywnie obsługują identyfikatory UUID

Który kierowca? Istnieją co najmniej dwa sterowniki JDBC typu open source dla Postgresa, obecny/starszy i nowy, przepisany „następnej generacji”. Są też inni kierowcy komercyjni.

„natywnie”? Czy możesz połączyć się z dokumentacją, którą czytałeś? Specyfikacja SQL nie ma typu danych dla UUID (niestety ☹), dlatego specyfikacja JDBC nie ma typu danych dla UUID. Jako obejście, sterownik JDBC dla Postgres używa setObject i getObject Metody na PreparedStatement przenoszą UUID przez przepaść między Java ↔ SQL ↔ Postgres. Zobacz przykładowy kod powyżej.

Jak mówi dokument PreparedStatement JDBC:

Jeśli wymagane są konwersje typu dowolnego parametru, należy użyć metody setObject z docelowym typem SQL.

Być może „natywnie” pomyliłeś natywne wsparcie Postgresa dla UUID jako typu danych z JDBC mającym typ danych UUID. Postgres rzeczywiście obsługuje UUID jako typ danych, co oznacza, że wartość jest przechowywana jako 128-bitowa, a nie wielokrotnie, jeśli byłaby przechowywana jako ciąg szesnastkowy ASCII lub Unicode. A bycie natywnym oznacza również, że Postgres wie, jak zbudować indeks na kolumnie tego typu.

We wspomnianym powyżej wpisie na blogu byłem mile zaskoczony tym, jak łatwo jest wypełnić tę przepaść między Java ↔ SQL ↔ Postgres . W moich pierwszych niewykształconych próbach pracowałem zbyt ciężko.

Kolejna uwaga dotycząca Postgresa obsługującego UUID… Postgres wie, jak przechowywać, indeksować i pobierać istniejące wartości UUID. Aby generować wartości UUID, musisz włączyć rozszerzenie Postgres (wtyczka) uuid-ossp . To rozszerzenie zawiera bibliotekę dostarczoną przez The OSSP Project do generowania różnych rodzajów wartości UUID. Zobacz mój blog, aby uzyskać instrukcje.

Przy okazji…

Gdybym wiedział, jak złożyć petycję do grupy ekspertów JDBC lub zespołu JSR o poinformowanie JDBC o UUID, z pewnością bym to zrobił. Robią to właśnie dla nowych typów daty i czasu zdefiniowanych w JSR 310:Date and Time API.

Podobnie, gdybym wiedział, jak złożyć petycję do komitetu normalizacyjnego SQL o dodanie typu danych UUID, zrobiłbym to. Ale najwyraźniej ta komisja jest bardziej tajna niż sowieckie Biuro Polityczne i wolniejsza niż lodowiec.