<commit_before>// Metadata created by nebel
//

[id="how-the-mysql-connector-maps-data-types_{context}"]
= How the MySQL connector maps data types

The {prodname} MySQL connector represents changes to rows with events that are structured like the table in which the row exists. The event contains a field for each column value. The MySQL data type of that column dictates how the value is represented in the event.

Columns that store strings are defined in MySQL with a character set and collation. The MySQL connector uses the column's character set when reading the binary representation of the column values in the binlog events. The following table shows how the connector maps the MySQL data types to both _literal_ and _semantic_ types.

* *literal type* : how the value is represented using Kakfa Connect schema types
* *semantic type* : how the Kakfa Connect schema captures the meaning of the field (schema name) 

[cols="2,2,6"]
|===
|MySQL type |Literal type |Semantic type

|`BOOLEAN, BOOL`
|`BOOLEAN`
a| _n/a_

|`BIT(1)`
|`BOOLEAN`
a| _n/a_

|`BIT(>1)`
|`BYTES`
a| io.debezium.data.Bits

NOTE: The `length` schema parameter contains an integer that represents the number of bits. The `byte[]` contains the bits in _little-endian_ form and is sized to contain the specified number of bits.

.example (where n is bits)
----
numBytes = n/8 + (n%8== 0 ? 0 : 1)
----

|`TINYINT`
|`INT8`
a| _n/a_
<commit_msg>DBZ-1800 Correct TINYINT mapping<commit_after>// Metadata created by nebel
//

[id="how-the-mysql-connector-maps-data-types_{context}"]
= How the MySQL connector maps data types

The {prodname} MySQL connector represents changes to rows with events that are structured like the table in which the row exists. The event contains a field for each column value. The MySQL data type of that column dictates how the value is represented in the event.

Columns that store strings are defined in MySQL with a character set and collation. The MySQL connector uses the column's character set when reading the binary representation of the column values in the binlog events. The following table shows how the connector maps the MySQL data types to both _literal_ and _semantic_ types.

* *literal type* : how the value is represented using Kakfa Connect schema types
* *semantic type* : how the Kakfa Connect schema captures the meaning of the field (schema name) 

[cols="2,2,6"]
|===
|MySQL type |Literal type |Semantic type

|`BOOLEAN, BOOL`
|`BOOLEAN`
a| _n/a_

|`BIT(1)`
|`BOOLEAN`
a| _n/a_

|`BIT(>1)`
|`BYTES`
a| io.debezium.data.Bits

NOTE: The `length` schema parameter contains an integer that represents the number of bits. The `byte[]` contains the bits in _little-endian_ form and is sized to contain the specified number of bits.

.example (where n is bits)
----
numBytes = n/8 + (n%8== 0 ? 0 : 1)
----

|`TINYINT`
|`INT16`
a| _n/a_

{'fraction_non_alphanumeric': 0.08794674141555711, 'fraction_numerical': 0.0094604064470918, 'mean_word_length': 4.316573556797021, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4675565', 'n_tokens_mistral': 897, 'n_tokens_neox': 857, 'n_words': 415}