handle changes in tablemap ids

[YousefED]

It is possible that a tableMap event is passed from the MySQL protocol, that changes the id of a table. e.g.:

Current tablemap:
112: tableA
113: tableB

It's possible to get a tableMap event "113: tableA". Currently zongji doesn't handle this, because it sees we already have "113". With my proposed change, we check for changes in tableName or number of columns.

To fix the root cause, I'm wondering why we need to do a _fetchTableInfo anyway. What information do we retrieve in _fetchTableInfo that's not already included in the tableMap message?

If we don't need to do the _fetchTableInfo, we don't need to pause the connection, and we can just always use the latest tableMap event, as recommended by the replication protocol. Let me know if you have more info about this

[nevill]

Good point. The reason is simple, I didn't know how Table_Map_Event is working at the time the code was born. It was simple to retrieve the table meta info by direct querying rather than parsing the packet.

[YousefED]

Thanks. I'm not an expert on the MySQL binlog protocol, but it seems like the charset information is not available there; correct? That might be the (unfortunate) reason this query is necessary