Spec-Zone .ru
спецификации, руководства, описания, API
|
MySQL, Connector/C ++, является совместимым с JDBC 4.0 API. См. examples/
каталог пакета
загрузки.
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
:
ResultSet::getUInt64()
ResultSet::getUInt()
Prepared_Statement::setUInt64()
Prepared_Statement::setUInt()
Соответствие 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
установка.
При использовании setString()
, не возможно установить max_allowed_packet
к значению, достаточно большому для строки до
передачи этого к MySQL, Connector/C ++. Тот параметр конфигурации не может быть изменен в
пределах сеанса.
Это различие от спецификации 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:
DatabaseMetadata::getCrossReference()
DatabaseMetadata::getExportedKeys()
MySQL, Connector/C ++, включает a Connection::getClientOption()
метод, который не включается в спецификацию API JDBC. Прототип:
void getClientOption(const std::string & optionName, void * optionValue)
Метод может использоваться, чтобы проверить значение набора свойств соединения, устанавливая
соединение с базой данных. Значения возвращаются через optionValue
параметр, который передают к методу с типом void *
.
В настоящий момент, getClientOption()
поддерживает выборку optionValue
из следующих опций:
metadataUseInfoSchema
defaultStatementResultType
defaultPreparedStatementResultType
Для metadataUseInfoSchema
, интерпретируйте
optionValue
параметр как булево по возврату.
Для defaultStatementResultType
и defaultPreparedStatementResultType
, интерпретируйте 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 также, кажется,
Чтобы сравнить значение с полем, используйте код такой в качестве следующего, вместо того, чтобы делать предположения об определенных значениях для атрибута:
// 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
.