[URGENT] Fix bug when long lines are truncated with extended inserts

[bibstha]

#473 introduced a bug where if we ARE using extended insert (default) and the table is long that the data needs to be truncated, then it wasn't getting truncated properly.

If a single line exceeds the MaxAllowedPacket, the next line should start with INSERT INTO tablename... but it doesn't.

This is what it looks like

But it should instead be like this

I haven't tested this, but looking the old PR's diff, this is how it should be?

[bibstha]

This is how things were in https://github.com/databacker/mysql-backup/pull/473/files#diff-70e106267ef4a71652c95e6eee62fa5d5c435cbb66d47f1afb4474b8fdcb30fd
And logically it makes sense. We should first truncate and then check if "INSERT" should be added or not.

[deitch]

Just a misplaced section? Ouch.

[bibstha]

Pinging @deitch as this will be breaking exports for many people.

[deitch]

Let's see if I get this. Originally, we assumed we always could do extended insert. So each table's insert was one large:

INSERT INTO table (<fields>) VALUES (...), (...), .... (...);

All of the records, from 1 row to however many are in the table, were after the VALUES. The only limit is the MaxAllowedPacket. Once we hit that, create a new INSERT row, and keep going.

#473 aded support for skip-extended-insert, which means, "do not do a super long INSERT, rather insert each row individually."

I think you are saying that skip-extended-insert works fine, creating a new INSERT INTO... for each row. But in the default case, where we have one long INSERT until we hit MaxAllowedPacket, then we broke it by no longer creating the INSERT INTO for the next inserts?

[deitch]

It would be nice to get a proper test for this. But this is too urgent to hold up. I will kick off CI. If you can think of a sane way to test, please add it.