On Feb 25, 2016, at 8:35, Michał Dulko <michal.du...@intel.com> wrote:
> We've faced similar issues in Cinder and as solution we've moved > filtering to Python code. Like in for example [1] or [2]. But no, we > haven't had UNIQUE constraint on the DB column in these cases, only on IDs. This is an interesting option. I see how option 1 (API case fold) is appealing, since our underlying storage (in the mysql case), is case insensitive. And when I think about it, I could see how for example "abc" is essentially the same thing as "ABC" and would be resilient to end users making differences in capitalization of metadata keys (imagine a typo of "DriveType" vs "Drivetype" where a user expects to set a value for the key and they are treated as different keys). The only concern I have about the case folding is when the data is visible to the user. That is, if a user sets a value for "DriveType" and they do 'nova aggregate-details' and see "drivetype" displayed, different than they specified or expected. In the case of aggregate metadata it doesn't seem too impactful since nova is supposed to be the only consumer of the metadata. But are we considering this as the consistent behavior across all APIs? -melanie
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
