tl;dr
myPreparedStatement.setObject(
… ,
java.util.UUID.randomUUID()
)
Подробности
(a) Покажете ни кода си.
PreparedStatement::setObject работи при подаване на java.util.UUID . Вероятно имате някакъв друг проблем във вашия код.
(b) Вижте моята публикация в блога UUID стойности от JDBC до Postgres за малко дискусия и примерен код.
// 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) Не съм сигурен какво имаш предвид под
Най-новите Java JDBC драйвери за postgres твърдят, че поддържат UUID изначално
Кой шофьор? Има поне два JDBC драйвера с отворен код за Postgres, текущият/наследен и нов пренаписан "следващо поколение". Има и други търговски драйвери.
"по рождение"? Можете ли да направите връзка към документацията, която сте прочели? SQL спецификацията няма тип данни за UUID (за съжаление ☹), следователно спецификацията JDBC няма тип данни за UUID. Като заобиколно решение JDBC драйверът за Postgres използва setObject и getObject методите на PreparedStatement преместват UUID през пропастта между Java ↔ SQL ↔ Postgres. Вижте примерния код по-горе.
Както се казва в PreparedStatement JDBC doc:
Ако се изискват преобразувания на произволен тип параметър, методът setObject трябва да се използва с целеви SQL тип.
Вероятно с "принципно" сте объркали естествената поддръжка на Postgres за UUID като тип данни с JDBC, имащ UUID тип данни. Postgres наистина поддържа UUID като тип данни, което означава, че стойността се съхранява като 128-бита, а не многократно, отколкото ако се съхранява като ASCII или Unicode шестнадесетичен низ. А това, че е роден, означава също, че Postgres знае как да изгради индекс върху колона от този тип.
Смисълът на моята публикация в блога, споменат по-горе, беше, че бях приятно изненадан от това колко лесно е да се преодолее тази пропаст между Java ↔ SQL ↔ Postgres . В първите си необразовани опити работих твърде усилено.
Друга забележка за Postgres, поддържащ UUID... Postgres знае как да съхранява, индексира и извлича съществуващи стойности на UUID. За генериране UUID стойности, трябва да активирате разширението (плъгин) Postgres uuid-ossp . Това разширение обхваща библиотека, предоставена от The OSSP Project за генериране на различни видове UUID стойности. Вижте моя блог за инструкции.
Между другото...
Ако знаех как да подам петиция пред експертната група на JDBC или екипа на JSR, за да информира JDBC за UUID, със сигурност бих щял. Те правят точно това за новите типове дата и час, дефинирани в JSR 310:API за дата и час.
По същия начин, ако знаех как да подам петиция до комисията по SQL стандарти за добавяне на тип данни UUID, щях да го направя. Но очевидно този комитет е по-таен от съветското Политбюро и по-бавен от ледник.
