{{ message }}
Repository navigation
fix(mysql): decode JSON columns in get_full_data - #130
Open
RitiGrover wants to merge 1 commit into
Open
RitiGrover wants to merge 1 commit into
RitiGrover wants to merge 1 commit into
Conversation
A plain SELECT returns JSON columns as their raw text serialization; asyncmy doesn't decode them automatically for a regular query result, unlike the binlog row-event decoder used for incremental sync, which already imports FIELD_TYPE.JSON and decodes it natively. So a full sync stored JSON columns as strings in Meilisearch while incremental updates stored them as proper objects/arrays. Use cursor.description to find JSON columns and json.loads() them, matching what the binlog path already does. Fixes long2ice#109
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
MySQL.get_full_dataruns a plainSELECTand yields whateverDictCursor.fetchall()returns. For aJSONcolumn, that's the raw text serialization (asyncmydoesn't decode it for a normal query result) - unlike the binlog row-event path used for incremental sync, which already importsFIELD_TYPE.JSONfromasyncmy.constantsand decodes it natively. So a full sync stores JSON columns as strings in Meilisearch, while incremental updates for the same table store them as proper objects/arrays.Motivation and Context
Fixes #109. Confirmed directly against a real MySQL 8 instance:
SELECTon aJSONcolumn viaasyncmy'sDictCursorreturns a Pythonstr, not adict/list.How Has This Been Tested?
asyncmy'sDictCursor.fetchall()returns JSON columns asstr, confirming the root cause.asyncmy.replication.row_eventsto confirm the binlog decoder already handlesFIELD_TYPE.JSON, which is why only the full-sync path is affected.test_get_full_data_decodes_json_columnstotests/test_mysql.py, following the existing file's pattern (connects to MySQL directly, no daemon/Meilisearch process needed). Confirmed it fails on the current code (JSON column comes back as a string) and passes with the fix.ruff check/ruff formatclean on the changed lines (the file has some pre-existing lint findings on lines I didn't touch - left those alone).I didn't touch the binlog path since it already decodes
JSONcorrectly; the fix is scoped toget_full_dataonly.