Skip to content

Conversation

magicdoom
Copy link
Owner

No description provided.

shyiko and others added 24 commits September 20, 2016 16:05
When we eventually reach EOF on an ever growing binlog, nextEvent
cannot read a new event because peek is -1, but this peek is saved
from the previous event reaching EOF and may be out of sync with
the underlying InputStream.

This change makes peek() always check the underlying stream if
it had just EOF'd (peek == -1)
ByteArrayInputStream peek may be wrong after EOF
Added support for the JSON type added to MySQL 5.7. This required adding a new `ColumnType` and a new method to deserialize the JSON value, although the deserialization simply returns the `byte[]` containing the internal binary representation of the JSON value.

In order to be useful, this binary representation needs to be parsed into something more useful. A new `JsonBinary` class was created that can perform this parsing and delegate to a `JsonFormatter` implementation when JSON objects or arrays are started/ended, when various name-value pairs are encountered in an object, when values are encountered in an array, and when scalar values are encountered (outside of a JSON object or array, which is not really standard JSON).

Since many clients will simply want to obtain a JSON string representation of the JSON value, a `JsonStringFormatter` class was added, and a `JsonBinary.parseAsString` utility method added to conveniently obtain the JSON string representation. Of course, if this is not sufficient, clients can either subclass `JsonStringFormatter` to customize the behavior or implement their own `JsonFormatter` with completely custom behavior.

Quite a few integration test methods were added to insert various JSON values into a table, read the corresponding `WriteRowsEventData` event for the INSERT, extract the binary JSON value from the event, and then compare the string representation of the JSON value to expected forms.

Note that MySQL does allow for some values within JSON objects and arrays to be of types other than boolean, numeric, and strings (per the JSON spec). For example, MySQL `BLOB`, `DATE`, `TIME`, `DATETIME`, and `TIMESTAMP` values can be used and are encoded as "opaque types", although the `JsonBinary` parser does know how to interpret this opaque forms and call appropriate methods on the `JsonFormatter`. The `JsonStringFormatter` simply encodes the temporal types as formatted dates, times, or timestamps, while all other opaque values are represented as Base64-encoded strings.

Also, MySQL does allow scalar values to be used in `JSON` columns outside of JSON objects and arrays. This does not adhere to the JSON spec, and as such the `JsonStringFormatter` simply returns the string representations of these scalar values. (Any other logic can be customized.)
Added support for MySQL JSON type
… listeners

Previously, GTIDs were updated at the same time the binlog filename and position were updated: after the event listeners were called. However, this means that the GTID set was not yet updated when the event listeners were called, meaning that the event listeners would see the old GTID set if they asked for it.

With this change, the GTID set is updated before the event listeners are called, and the binlog filename and position (which reference the _next_ event) are updated after the event listeners are called. This ensures that the event listeners see the event's correct GTID set and binlog filename and position.
Changed the client so that GTIDs are updated before calling the event listeners
@magicdoom magicdoom merged commit 5da440d into magicdoom:master Dec 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants