22.4.9. MySQL, Connector/C ++ Примечания Использования

MySQL, Connector/C ++ sql::DataType class определяет следующие стандартные типы данных JDBC: UNKNOWN, BIT, TINYINT, SMALLINT, MEDIUMINT, INTEGER, BIGINT, REAL, DOUBLE, DECIMAL, NUMERIC, CHAR, BINARY, VARCHAR, VARBINARY, LONGVARCHAR, LONGVARBINARY, TIMESTAMP, DATE, TIME, GEOMETRY, ENUM, SET, SQLNULL.

MySQL, Connector/C ++, не поддерживает следующие стандартные типы данных JDBC: ARRAY, BLOB, CLOB, DISTINCT, FLOAT, OTHER, REF, STRUCT.

DatabaseMetaData::supportsBatchUpdates() возвраты true потому что MySQL поддерживает пакетные обновления вообще. Однако, MySQL, Connector/C ++ API, не обеспечивает вызовов API пакетных обновлений.

Два non-JDBC метода, которым позволяют Вы выбрать и установить целых без знака: getUInt64() и getUInt(). Они доступны для ResultSet и Prepared_Statement:

Соответствие getLong() и setLong() методы были удалены.

DatabaseMetaData::getColumns() у метода есть 23 столбца в его наборе результатов, а не 22 столбца, определенные JDBC. Первые 22 столбца как описываются в документации JDBC, но столбец 23 нов:

23. IS_AUTOINCREMENT: Строка, которая является "ДА", если столбец является столбцом автоприращения, "НЕТ" иначе.

MySQL, Connector/C ++, может возвратить различные метаданные для того же самого столбца, в зависимости от метода, который Вы вызываете.

Предположите, что у Вас есть столбец, который принимает набор символов и сопоставление в его спецификации, и Вы определяете двоичное сопоставление, такое как:

VARCHAR(20) CHARACTER SET utf8 COLLATE utf8_bin

Сервер устанавливает BINARY флаг в метаданных набора результатов этого столбца. ResultSetMetadata::getColumnTypeName() метод использует метаданные и сообщит, из-за BINARY флаг, что имя типа столбца BINARY. Это иллюстрируется здесь:

mysql> CREATE TABLE varbin (a VARCHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);Query OK, 0 rows affected (0.00 sec)mysql> select * from varbin;Field   1:  `a`Catalog:    `def`Database:   `test`Table:      `varbin`Org_table:  `varbin`Type:       VAR_STRINGCollation:  latin1_swedish_ci (8)Length:     20Max_length: 0Decimals:   0Flags:      BINARY0 rows in set (0.00 sec)mysql> SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='varbin'\G*************************** 1. row ***************************           TABLE_CATALOG: NULL            TABLE_SCHEMA: test              TABLE_NAME: varbin             COLUMN_NAME: a        ORDINAL_POSITION: 1          COLUMN_DEFAULT: NULL             IS_NULLABLE: YES               DATA_TYPE: varcharCHARACTER_MAXIMUM_LENGTH: 20  CHARACTER_OCTET_LENGTH: 60       NUMERIC_PRECISION: NULL           NUMERIC_SCALE: NULL      CHARACTER_SET_NAME: utf8          COLLATION_NAME: utf8_bin             COLUMN_TYPE: varchar(20)              COLUMN_KEY:                   EXTRA:              PRIVILEGES: select,insert,update,references          COLUMN_COMMENT:1 row in set (0.01 sec)

Однако, INFORMATION_SCHEMA не подает подсказки COLUMNS таблица, которую метаданные будут содержать BINARY флаг. DatabaseMetaData::getColumns() использование INFORMATION_SCHEMA и сообщит об имени типа VARCHAR для того же самого столбца. Это также возвращает различный код типа.

Вставляя или обновляя BLOB или TEXT столбцы, MySQL, Connector/C ++, разработчикам советуют не использовать setString(). Вместо этого используйте выделенный setBlob() API-функция.

Использование setString() может вызвать Пакет слишком большое сообщение об ошибке. Ошибка происходит если длина строки, которую передают к использованию соединителя setString() превышает max_allowed_packet (минус несколько байтов, зарезервированных в протоколе в целях управления). Эта ситуация не обрабатывается в MySQL, Connector/C ++, потому что это могло привести к вопросам безопасности, таким как выделение чрезвычайно памяти большой емкости запрашивает из-за недоброжелательно длинных строк.

Если setBlob() используется, эта проблема не возникает потому что setBlob() проявляет подход потоковой передачи, основанный на std::istream. Отправляя данные от потока до MySQL Server, MySQL, Connector/C ++, разделяет поток на блоки, подходящие для MySQL Server, используя ток max_allowed_packet установка.

Это различие от спецификации JDBC гарантирует, что MySQL, Connector/C ++, не уязвим для атак лавинной рассылки памяти.

Вообще, MySQL, Connector/C ++, работает с MySQL 5.0, но это не полностью поддерживается. Некоторые методы, возможно, не доступны, соединяясь с MySQL 5.0. Это - то, потому что Информационная схема используется, чтобы получить требуемую информацию. Нет никаких планов улучшить поддержку 5.0, потому что текущая версия GA MySQL Server 5.6. MySQL, Connector/C ++, прежде всего предназначается в версии MySQL Server GA, которая доступна на ее выпуске.

Следующие методы бросают a sql::MethodNotImplemented исключение, когда Вы соединяетесь с сервером MySQL ранее чем 5.1:

MySQL, Connector/C ++, включает a Connection::getClientOption() метод, который не включается в спецификацию API JDBC. Прототип:

void getClientOption(const std::string & optionName, void * optionValue)

Метод может использоваться, чтобы проверить значение набора свойств соединения, устанавливая соединение с базой данных. Значения возвращаются через optionValue параметр, который передают к методу с типом void *.

В настоящий момент, getClientOption() поддерживает выборку optionValue из следующих опций:

Свойство соединения может быть установлено или устанавливая соединение через карту свойства соединения, или использование void Connection::setClientOption(const std::string & optionName, const void * optionValue) где optionName присваивается значение metadataUseInfoSchema.

Некоторые примеры:

bool isInfoSchemaUsed;conn->getClientOption("metadataUseInfoSchema", (void *) &isInfoSchemaUsed);int defaultStmtResType;int defaultPStmtResType;conn->getClientOption("defaultStatementResultType", (void *) &defaultStmtResType);conn->getClientOption("defaultPreparedStatementResultType", (void *) &defaultPStmtResType);

MySQL, Connector/C ++, поддерживает следующие методы, не найденные в стандарте API JDBC:

std::string MySQL_Connection::getSessionVariable(const std::string & varname)

void MySQL_Connection::setSessionVariable(const std::string & varname, const std::string & value)

Эти методы получают и устанавливают переменные сеанса MySQL. Оба - элементы MySQL_Connection class.

getSessionVariable() эквивалентно выполнению следующего и выборке первого возвращаемого значения:

SHOW SESSION VARIABLES LIKE "<varname>"

Можно использовать "%" и "_" символы образца SQL в <varname>.

setSessionVariable() эквивалентно выполнению:

SET SESSION <varname> = <value>

Выборка значения столбца может иногда возвращать различные значения в зависимости от того, выполняется ли вызов от Оператора или Готового Оператора. Это - то, потому что протокол, используемый, чтобы связаться с сервером, отличается в зависимости от того, используются ли Оператор или Готовый Оператор.

Чтобы иллюстрировать это, рассмотрите случай, где столбец был определен как тип BIGINT. Самое отрицательное BIGINT значение тогда вставляется в столбец. Если Оператор и Готовый Оператор создаются, которые выполняют a GetUInt64() вызовите, тогда результаты будут отличаться в каждом случае. Оператор возвращает максимальное положительное значение для BIGINT. Готовый Оператор возвращается 0.

Различие следует из факта, что Операторы используют текстовый протокол, и Готовые Операторы используют протокол двоичной синхронной передачи данных. С протоколом двоичной синхронной передачи данных в этом случае, двоичное значение возвращается из сервера, который может быть интерпретирован как int64. В предыдущем сценарии очень большая отрицательная величина выбирается с GetUInt64(), который выбирает целых без знака. Поскольку большая отрицательная величина не может быть заметно преобразована в значение без знака, 0 возвращается.

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

Хотя это очень редко, есть некоторые случаи, куда Операторы и Готовые Операторы могут неожиданно возвратить различные значения, но это обычно только происходит в крайних случаях, таких как упомянутый тот.

Документация JDBC перечисляет много полей для DatabaseMetaData class. JDBC также, кажется, определяет определенные значения для тех полей. Однако, MySQL, Connector/C ++, не определяет определенные значения для тех полей. Внутренне перечисления используются, и компилятор определяет значения, чтобы присвоиться к полю.

Чтобы сравнить значение с полем, используйте код такой в качестве следующего, вместо того, чтобы делать предположения об определенных значениях для атрибута:

// dbmeta is an instance of DatabaseMetaDataif (myvalue == dbmeta->attributeNoNulls) {    ...}

Обычно myvalue будет столбец от набора результатов, содержащего информацию о метаданных. MySQL, Connector/C ++, не гарантирует это attributeNoNulls 0. Это может быть любое значение.

Программируя хранимые процедуры, JDBC имеет доступный дополнительный class, дополнительный уровень абстракции для вызываемых операторов, CallableStatement class. Поскольку этот class не присутствует в MySQL, Connector/C ++, используйте методы от Statement и PreparedStatement классы, чтобы выполнить использование хранимой процедуры CALL.