Comment 19 for bug 1538011

Thanks for the clarification, melanie. Yes, aggregate metadata is also potentially user facing in that we have API support making it so. I also agree that I'm not fan of modifying input.

Because this only affects new key creation in the case of aggregate metadata, if we can't do the database change, we could just throw a validation error for new keys that aren't all lowercase. Sean and I had originally discussed modifying the JSON validation to that effect. We would still need additional error checking to handle the duplicate case, but at least that would set the user expectation.

For the larger metadata case, I'm of the opinion that users should be able to set the keys to whatever capitalization strategy they want. If we can add a constraint to prevent duplicate key names in some way, we could maintain an internal mapping that preserves the original case. It seems like over-engineering and added complexity, but that's my thought on it. Of course the ideal solution is to just fix the columns in the database.