On 03/11/2014 05:50 PM, Clint Byrum wrote:

But MySQL can't possibly know what you _meant_ when you were inserting
data. So, if you _assumed_ that the database was UTF-8, and inserted
UTF-8 with all of those things accidentally set for latin1, then you
will have UTF-8 in your db, but MySQL will think it is latin1. So if you
now try to alter the table to UTF-8, all of your high-byte strings will
be double-encoded.

It unfortunately takes analysis to determine what the course of action
is. That is why we added the check to Heat, so that it would complain
very early if your tables and/or server configuration were going to
disagree with the assumptions.

I find it interesting that the db migrations only specify character encodings for mysql, not any other database. At the same time, devstack seems to create the nova* databases as latin1 for historical reasons.

postgres is supported under devstack, so I think this will end up causing a devstack/postgres setup to use utf-8 for most things but latin1 for the nova* databases, which seems odd.

Chris

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to