22.3.5.2. Примечания Реализации API JDBC

MySQL передачи Connector/J все тесты в публично доступной версии соответствия Sun JDBC тестирует комплект. Этот раздел сообщает подробности на уровне интерфейса интерфейсом о решениях реализации, которые могли бы влиять, как Вы кодируете приложения с MySQL, Connector/J. Спецификация JDBC неопределенна о том, как определенная функциональность должна быть реализована, или спецификация включает дрейфу в реализации.

BLOB

Запускаясь с версии 3.1.0 Connector/J, можно эмулировать BLOB с локаторами, добавляя свойство emulateLocators=true к Вашему URL JDBC. Используя этот метод, драйвер задержит загрузку фактических данных BLOB, пока Вы не получите другие данные и затем используете методы извлечения (getInputStream(), getBytes(), и т.д) на потоке данных BLOB.

Следует использовать псевдоним столбца со значением столбца к подлинному имени BLOB, например:
```
SELECT id, 'data' as blob_data from blobtable
```
Следует также следовать за этими правилами:
- SELECT должен сослаться только на одну таблицу. У таблицы должен быть первичный ключ.
- SELECT должен исказить исходное имя столбца BLOB, определенное как строка, к альтернативному названию.
- SELECT должен покрыть все столбцы, которые составляют первичный ключ.
Реализация BLOB не позволяет оперативную модификацию (они - копии, как сообщающийся DatabaseMetaData.locatorsUpdateCopies() метод). Из-за этого используйте соответствие PreparedStatement.setBlob() или ResultSet.updateBlob() (в случае обновляемых наборов результатов), методы, чтобы сохранить возвращается к базе данных.
CallableStatement

Запускаясь с Connector/J 3.1.1, хранимые процедуры поддерживаются, соединяясь с версией 5.0 MySQL или более новым использованием CallableStatement интерфейс. В настоящий момент, getParameterMetaData() метод CallableStatement не поддерживается.
CLOB

Реализация CLOB не позволяет оперативную модификацию (они - копии, как сообщающийся DatabaseMetaData.locatorsUpdateCopies() метод). Из-за этого используйте PreparedStatement.setClob() метод, чтобы сохранить возвращается к базе данных. У API JDBC нет a ResultSet.updateClob() метод.
Соединение

В отличие от pre-Connector/J JDBC драйвер (MM.MySQL), isClosed() метод не проверяет с помощью ping-запросов сервер, чтобы определить, доступно ли это. В соответствии со спецификацией JDBC, это только возвращает true если closed() был вызван на соединении. Если Вы должны определить, допустимо ли соединение все еще, выпустите простой запрос, такой как SELECT 1. Драйвер выдаст исключение, если соединение будет больше не действительно.
DatabaseMetaData

Информация о внешнем ключе (getImportedKeys()/getExportedKeys() и getCrossReference()) только доступно от InnoDB таблицы. Использование драйвера SHOW CREATE TABLE чтобы получить эту информацию, так, если бы какие-либо другие механизмы хранения добавляют поддержку внешних ключей, драйвер прозрачно поддерживал бы их также.
PreparedStatement

PreparedStatements реализуются драйвером, поскольку у MySQL нет готовой функции оператора. Из-за этого драйвер не реализует getParameterMetaData() или getMetaData() поскольку это потребовало бы, чтобы у драйвера был полный синтаксический анализатор SQL в клиенте.

Запускаясь с MySQL версии 3.1.0 сторона сервера Connector/J, подготовленные операторы и закодированные двоичным файлом наборы результатов используются, когда сервер поддерживает их.

Заботьтесь при использовании стороны сервера подготовленный оператор с большими параметрами, которые устанавливаются, используя setBinaryStream(), setAsciiStream(), setUnicodeStream(), setBlob(), или setClob(). Чтобы повторно выполнить оператор с любым большим параметром, измененным на небольшой параметр, вызвать clearParameters() и установленный все параметры снова. Причина этого следующие:
- И во время стороны сервера подготовленные операторы и во время клиентской эмуляции, большие данные передаются только когда PreparedStatement.execute() вызывается.
- Как только это было сделано, поток, используемый, чтобы считать данные на стороне клиента, закрывается (согласно спецификации JDBC), и не может быть считан из снова.
- Если параметр изменяется от большого до небольшого, драйвер должен сбросить серверное состояние готового оператора, чтобы позволить параметр, который изменяется, чтобы взять место предшествующего большого значения. Это удаляет все большие данные, которые были уже отправлены серверу, таким образом требуя, чтобы данные были снова посланы, используя setBinaryStream(), setAsciiStream(), setUnicodeStream(), setBlob() или setClob() метод.
Следовательно, чтобы изменить тип параметра к небольшому, следует вызвать clearParameters() и установленный все параметры готового оператора снова прежде, чем это сможет быть повторно выполнено.
ResultSet

По умолчанию ResultSets полностью получаются и сохранены в памяти. В большинстве случаев это - самый эффективный способ работать, и из-за проекта протокола сети MySQL легче реализовать. Если Вы работаете с ResultSets, которые имеют большое количество строк или больших значений, и не могут выделить пространство "кучи" в Вашей JVM для требуемой памяти, можно сказать, что драйвер, чтобы передать результаты потоком поддерживает одну строку за один раз.

Чтобы добавить эту функциональность, создайте a Statement экземпляр следующим способом:
```
stmt = conn.createStatement(java.sql.ResultSet.TYPE_FORWARD_ONLY,              java.sql.ResultSet.CONCUR_READ_ONLY);stmt.setFetchSize(Integer.MIN_VALUE);
```
Комбинация прямого единственного, набора результатов только для чтения, с размером выборки Integer.MIN_VALUE служит сигналом к драйверу, чтобы передать строку строкой наборов результатов потоком. После этого любые наборы результатов, создаваемые с оператором, будут полученной строкой строкой.

Есть некоторые протесты с этим подходом. Следует считать все строки в наборе результатов (или закрыть его) прежде, чем можно будет выпустить любые другие запросы на соединении, или исключение будет выдано.

Самое раннее блокировки эти операторы хранение может быть выпущено (ли они быть MyISAM блокировки на уровне таблицы или блокировки на уровне строки в некотором другом механизме хранения такой как InnoDB) то, когда оператор завершается.

Если оператор в пределах контекста транзакции, то блокировки выпускаются, когда транзакция завершается (который подразумевает, что оператор должен завершиться сначала). Как с большинством других баз данных, операторы не полны, пока все результаты, ожидающие на операторе, не читаются, или активный набор результатов для оператора закрывается.

Поэтому, используя передающие потоком результаты, обработайте их как можно быстрее, если Вы хотите поддержать параллельный доступ к таблицам, на которые ссылается оператор, производящий набор результатов.
ResultSetMetaData

isAutoIncrement() метод только работает при использовании серверов MySQL 4.0 и более новый.
Оператор

При использовании версий драйвера JDBC ранее чем 3.2.1, и соединенный с версиями сервера ранее чем 5.0.3, setFetchSize() метод не имеет никакого эффекта, кроме переключить набор результатов, передающий потоком как описано выше.

Connector/J 5.0.0 и позже включают поддержку обоих Statement.cancel() и Statement.setQueryTimeout(). И потребуйте MySQL 5.0.0 или более нового сервера, и потребуйте, чтобы отдельное соединение вышло KILL QUERY оператор. В случае setQueryTimeout(), реализация создает дополнительный поток, чтобы обработать функциональность тайм-аута.

Отметить

Отказы отменить оператор для setQueryTimeout() может проявиться как RuntimeException вместо того, чтобы перестать работать тихо, как нет в настоящий момент никакого способа разблокировать поток, который выполняет запрос, отменяемый из-за истечения тайм-аута, и имейте это, выдают исключение вместо этого.

Отметить

Оператор MySQL KILL QUERY (который является тем, что драйвер использует для реализации Statement.cancel()) недетерминировано; таким образом избегите использования Statement.cancel() если возможный. Если никакой запрос не будет в процессе, то следующий выпущенный запрос будет уничтожен сервером. Это состояние состязания предотвращается с Connector/J 5.1.18.

MySQL не поддерживает курсоры SQL, и драйвер JDBC не эмулирует их, таким образом, setCursorName() не имеет никакого эффекта.

Connector/J 5.1.3 и позже включают два дополнительных метода:
- setLocalInfileInputStream() наборы InputStream экземпляр, который будет использоваться, чтобы отправить данные серверу MySQL для a LOAD DATA LOCAL INFILE оператор, а не a FileInputStream или URLInputStream это представляет путь, данный как параметр оператору.
  
  Этот поток будет считан в завершение после выполнения a LOAD DATA LOCAL INFILE оператор, и будет автоматически закрыт драйвером, таким образом, это должно будет быть сброшено перед каждым звонком execute*() это заставило бы сервер MySQL запрашивать данные, чтобы выполнить запрос на LOAD DATA LOCAL INFILE.
  
  Если это значение устанавливается в NULL, драйвер вернется к использованию a FileInputStream или URLInputStream как требуется.
- getLocalInfileInputStream() возвраты InputStream экземпляр, который будет использоваться, чтобы отправить данные в ответ на a LOAD DATA LOCAL INFILE оператор.
  
  Этот метод возвраты NULL если никакой такой поток не был установлен, используя setLocalInfileInputStream().