On 09/18/2014 07:57 PM, Christopher Yeoh wrote: > On Thu, 18 Sep 2014 12:12:28 -0400 > Sean Dague <s...@dague.net> wrote: >>> When we can return the json-schema to user in the future, can we say >>> that means API accepting utf8 or utf8mb4 is discoverable? If it is >>> discoverable, then we needn't limit anything in our python code. >> >> Honestly, we should accept utf8 (no weird mysqlism not quite utf8). We >> should make the default scheme for our dbs support that on names (but >> only for the name columns). The failure of a backend to do utf8 for >> real should return an error to the user. Let's not make this more >> complicated than it needs to be. > > I agree that discoverability for this is not the way to go - I think its > too complicated for end users. I don't know enough about mysql to know > if utf8mb4 is going to a performance issue but if its not then we > should just support utf-8 properly. > > We can we can catch the db errors. However whilst converting db > errors causing 500s is fairly straightforward when an error occurs that > deep in Nova it also means a lot of potential unwinding work in the db > and compute layers which is complicated and error prone. So i'd prefer > to avoid the situation with input validation in the first place.
Honestly, it's not that bad. We've been catching and translating those errors in the past. Not supporting the whole utf8 charset is silly, it's there for a reason. And the point being, we'll make the db names fields catch up over time. Again, skate to where you think the puck is going to be. -Sean -- Sean Dague http://dague.net _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev