Comment 15 for bug 1538011

I don't really like the idea of casefolding data set by the user and can be read by the user. Do we really want the precedent of changing data provided by the user because MySQL? I understand this is the only way given the unique constraint on the key. Is removing the unique constraint an option?

If there's no a unique constraint, then we would have to add checking at the sqlalchemy/api.py layer that finds the exact match among multiple results, for example, FOO foo FoO as mentioned in IRC to ensure we read/update/delete the right record. And we can raise on our own in the case of duplicates.

I can understand the argument that this isn't a Big Deal for aggregate metadata being that the consumer of the data is Nova. But if we broaden the issue to say, user metadata, are we still going to want to change all the keys to lowercase? If someone has a program that will do something based on the value of a metadata key, their code may not find the same key they had set earlier. Example: user program sets MyMetadataKey=somevalue and then they try to access "MyMetadataKey" in a queried instance and get a KeyError because it's now "mymetadatakey".