MySQL table-level non-default collations get ignored by mysql if they come before a charset declaration

[Former user]

(original reporter: taavi) MySQL is picky with respect to the ordering of CHARSET and COLLATE clauses on a table definition.

If CHARSET comes first, everything's fine. But if COLLATE comes first, it gets overridden by the subsequent CHARSET (which tosses the collation back to the per-charset default.

I haven't had a chance to poke further into how to fix it, but I do have a repro script for now.

I originally found this while reflecting tables, but it looks like the bug is just in the CREATE rendering.

[Former user]

(original author: taavi) This appears to happen in 0.6.8 and 0.7.1. I haven't tried the development tip yet.

[Mike Bayer]

nothing has changed re: mysql in awhile. if the create rendering is off its a pretty easy fix.

[Mike Bayer]

0.6: 88f345aa0ab05ac4d35ecf6048e7badc52ff80f7 0.7: a9ebba3e1b135f1b5ac612844dce1e34e4d0eeee undo the change with the _ in 539c7a1ca26d4338f2cec326dad7a17a2f0ac267, this doesn't actually prevent create->reflect->create round trips

[Mike Bayer]

Removing milestone: 0.6.9 (automated comment)