Issue 603 - inconsistent information_schema.columns types #712
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| try: | ||
| return mysql.connect(charset="utf8", use_unicode=True, **self._args) | ||
| conn = mysql.connect(charset="utf8mb4", use_unicode=True, **self._args) | ||
| conn.set_charset_collation(charset="utf8mb4", collation="utf8mb4_0900_ai_ci") |
There was a problem hiding this comment.
This collation was added in MySQL 8.0.1 released sometime around 2018. We might expect much older versions for the typical migration/replication use cases for which data-diff is used (usually for the purpose of leaving those older versions). Should we make it so that the absence of this collation does not raise an error a few lines below?
And a second question: "ci" means "case insensitive". Does it make bisection by textual PKs, as well as where-filtering, case-insensitive by default, which might come as a surprise to users?
There was a problem hiding this comment.
@nolar I think I need to look into it more deeply, but from what I can tell, all of the default collations are _ci
|
This pull request has been marked as stale because it has been open for 60 days with no activity. If you would like the pull request to remain open, please comment on the pull request and it will be added to the triage queue. Otherwise, it will be closed in 7 days. |
|
Although we are closing this pull request as stale, it's not gone forever. PRs can be reopened if there is renewed community interest. Just add a comment and it will be reopened for triage. |
For some mysql users,
select DATA_TYPE FROM information_schema.columnsis returning b'str'It seems collation ~can~ affect the QueryResult types returned by
mysql-connector-python. Strings can be returned as byte strings (or byte arrays??) when using_bincollations. In addition char_set="utf8" is actually an alias that can cause more inconsistencies.See:
This PR explicitly sets the encoding and collation used by the client to (hopefully) resolve #603 -- I'm not able to reproduce that exact scenario, but a similar one when changing the collation locally.
Note the column level collation setting for "DATA_TYPE", setting it in the client overrides this and any other settings.